It’s been a couple of weeks since the first public disclosure of the Log4j vulnerability. A lot has happened - perhaps the understatement of the year. Several rounds of new patches have been issued from the Apache Software foundation and others as new information about this unprecedented security issue is discovered. We’re now learning about some of the more sinister aspects of this situation with nation state actors exploiting the vulnerability.
Contrast Security is a company focused on protecting customers from application attacks of all sorts. We’ve detected and stopped millions of attack events. In fact, we’ve earlier shown how Contrast was able to block log4j-related exploits on Day Zero. This gives us a unique vantage point from which to look at the situation around the log4j incident and see what we can learn. After the public disclosure of the Log4j vulnerability, we dove into our own data to look for any clues to better understand what’s going on.
Reviews of our historical data show that in the week starting November 24, 2021, Contrast Security started seeing a sharp 111% increase in expression language and deserialization attacks. This timing coincides with when attackers started reconnaissance on global companies looking for Java applications that were hosting exploitable Log4j versions. By the time the vulnerability was disclosed to the public on December 9, 2021, expression language and deserialization attack volumes had increased 136% based on our data. With that in mind, Contrast Security encourages you to:
1) Focus on reducing underlying vulnerabilities.
CVE-2021-44228 leverages 3 weaknesses - expression language, deserialization of untrusted data, and ognl-injection - to create a unique attack opportunity. Those underlying weaknesses are preventable and should be managed during the development of applications. Remove the application security vulnerabilities, then exposure to CVE’s and zero days will disappear. Of note, relying solely on SCA tools to perform simple database look-ups won’t help in this case with zero days.
And just to hit home the point that you need to be proactively protected, there were nearly 40 a day to contend with.
2) Leverage protection that handles zero day attacks
Many security initiatives exist within resource constrained security teams to prevent CVEs. These initiatives consume resources at the expense of a more valuable approach - a security program configured to block zero-day attacks. Effective corporate security programs, and the software they leverage, know the software in their portfolio, the vulnerabilities to be contained, and have protections in place that cover those vulnerabilities from tomorrow’s attack variations.
This second point is really critical to understand and implement. Doing so will dramatically reduce damage from the current Log4j vulnerability and future application attacks. Intelligent runtime protection for applications that can block entire classes of vulnerabilities (injection attacks, for example) buys precious time to get clarity on the vulnerability and manage it appropriately (develop and deploy a patch). The runtime protection Contrast offers is not signature based, therefore it’s at the ready and standing guard 24x7, blocking attacks before they’re even known.
Where to start? First, take a look at our updated guidance on how to address the Log4j issue. In addition, here’s a blog and video demonstrating our ability to detect and stop the Log4j attack. Next, Contrast Security has made available a no fee tool - Safelog4j - that you can use to protect your applications immediately. Finally, connect with us to learn how we can help in this situation and others that will likely turn-up going forward.
