In December of 2021 a critical vulnerability was discovered in Log4j. The Apache Log4j Project is among the most deployed pieces of open-source software, providing logging capabilities for Java applications. After the public announcement of a remote code execution vulnerability within this pervasive software, attacks soared as hackers exploited vulnerable systems globally.
In response, the Cybersecurity and Infrastructure Security Agency (CISA) issued Emergency Directive 22-02 on Dec. 17, which directed U.S. federal government agencies to patch, mitigate or completely remove all applications and services affected by the Log4j exploits. Just a few weeks later, the Federal Trade Commission (FTC) issued another directive warning members of the financial penalties that they would face for not patching the vulnerabilities.
Eventually the Log4j exploit was patched in the upstream distribution. After an intense round of patching, IT support staffs were able to come up for a breath of air.
Or did they?
Multiple cybersecurity companies including Qualys, PacketLabs, Rezilion and others released reports in April and May of this year that upwards of 30% of companies are still struggling to fully patch the various exploits associated with the Log4j series of vulnerabilities.
There are several problems with patching outside of the automatic update cycle that we have for desktop operating systems and applications. Specific to Log4j, the software has been used in a wide variety of programs that are not documented, so you might not even know where you have Log4j in your environment. And in general, the number of vulnerabilities being discovered has not stopped. IT staffs are overwhelmed, and the continued patching of vulnerable systems comes at a time when IT support groups are shrinking, not growing. Just in the past week, the Neustar Security Services threat research department has released Web Application Firewall (WAF) rules for new SQL vulnerabilities discovered in SonicWall and PrestaShop software.
The critical nature of vulnerability patching and speed of patching has never been more apparent. Palo Alto’s Unit 42 stated in their 2022 Incident Response Report that hackers begin scanning for publicly exposed exploits within 15 minutes of the exploit being made public. But in a web application world, it’s reckless to blindly update your application stack without testing, and testing takes time, usually 30-90 days, well outside of the time that it takes to make exploit tools.
I’ve seen our customers reduce the burden on IT staff as they have deployed UltraWAF. UltraWAF is a cloud service that we offer that sits in front of a customer’s web application to detect and block malicious web requests. It includes signatures for vulnerabilities to quickly allow new virtual patches to be deployed in the cloud, blocking hackers from exploiting vulnerabilities like we saw with Log4j and SQL Injection attacks as well as numerous other vulnerabilities.
There are some reasons why virtual patching with UltraWAF makes sense:
- Many WAF rules provide broad protections against classes of attack. For instance, if a Content Management System (CMS) has a SQL Injection (SQLi) vulnerability and you already have SQLi countermeasures enabled, you don’t need a specific rule or signature for that vulnerability because you are already protected. Virtual patches for specific point vulnerabilities are developed and published by our threat research team and can be implemented instantly on the WAF once it is available. This reduces the time and level of effort that you need to analyze the vulnerability, develop your own custom signature, test the signature against an exploit, and deploy it into production. Specifically for Log4j, we published 4 distinct rules to detect either the exploit itself or the payload attached to it.
- Virtual patches can be used even if you do not know if you have that vulnerability in your application. This gives you time to inventory your application stack to confirm or deny the existence of the responsible software and version.
- WAFs are deployed in front of the web application, so a temporary virtual patch gives you time to test and deploy a permanent fix to a vulnerability. This is even more important during times when you have a change freeze such as during tax season or the holiday shopping season.
- Customers who have, or who don’t know if they have, software vulnerable to attacks can rest easier knowing that they have a cloud-based virtual patching solution in place in conjunction with a full-featured Web Application Firewall (WAF) with a simple intuitive interface. Deploying a solution like this minimizes the emergency and out-of-schedule patching and allows IT teams to concentrate on their normal daily activities. Knowing that a virtual patch has already been deployed with a cloud-based WAF allows CISOs and CIOs to have peace-of-mind that their applications have been protected against vulnerabilities.
Vulnerabilities like Log4j are not one-offs and we will continue to see them in the future. Future vulnerabilities will impact your enterprise to some degree. They might not result in a compromise of data or a loss of application integrity, but they definitely will cause an impact in the number of staff hours required to mitigate. Successful online businesses make sure that their security strategy and technologies are appropriate to counter the threats that they could face.
We would be happy to discuss your application security needs and help you evaluate whether UltraWAF would be a useful addition to your IT security posture. Contact us today for a consultative discussion of your strategy.
