One year after Log4Shell, firms still struggle to hunt down Log4j

It’s been one year since a CVE identifier was made available for the infamous Log4j flaw — CVE-2021-44228, commonly referred to as Log4Shell — on Dec. 10, 2021. 

Log4Shell has been called the single biggest, most critical vulnerability in the history of computing: “arguably the most severe vulnerability ever,” as Ars Technica put it. Security pros’ descriptions were "bordering on the apocalyptic," the Washington Post said at the time.

Forget baking Christmas cookies. Instead, security teams spent their weekends scrambling to track down the ubiquitous library, given that the flaw was both a.) drop-dead simple to exploit and b.) already being exploited in the wild. Successful attacks using Log4Shell can allow unauthenticated remote code execution (RCE), granting attackers control over both an exploited application and the server it sits on. 

Hunting down the Log4j library was easier said than done: As security expert Marcus Hutchins said at the time, millions of applications use Log4j for logging. According to Contrast’s internal research, around 64% of Java applications use Log4j. That’s grim, given that  the only thing an attacker needs to do to exploit Log4Shell is to feed a special string to a vulnerable app.

One year on, people are asking: How’s that apocalypse going? How thoroughly has Log4j been ferreted out and patched, and what lessons has the horror show taught us? Read on for answers to those and other Log4Shell questions from Contrast Security CISO David Lindner. 

What’s the biggest Log4Shell lesson for enterprises? 

David Lindner: There are currently just over 68 CVEs released per day in 2022, according to CVE.icu. Even the best security testing in the world cannot find all of these and notify you of them. What we have learned is teams must rely on real-time protection for their applications to protect against zero days such as the issue with Log4j. This is no different than some of the technologies released in the *nix systems [i.e., operating systems similar to Unix, such as Linux, FreeBSD,and Mac OS X] years ago like DEP and ASLR. 

These runtime protections were designed to completely stomp out certain types of vulnerability classes and prevent attacks. The same technology exists for applications, and it is called Runtime Application Protection [aka Runtime Application Self-Protection, or RASP]. Runtime Application Protection provides zero-day protection immediately and should be one layer of the security onion in your toolbox.

What security issues did the vulnerability expose? 

David Lindner: Log4j exposed many things when it comes to security issues:

• Organizations struggled (and are still struggling) to find where Log4j was used. They do not have accurate asset management or Software Bill of Materials (SBOMs) of their systems to provide them with the ability to quickly identify problem areas.
• Once organizations identified all their Log4j, they were not sure where to start to upgrade, and in most cases found themselves waiting on vendors to upgrade the systems first.
• Only 50% of Log4j has been updated in one year’s time. It is still hard to manage third party libraries even when we know there are egregious and critical vulnerabilities.
• The biggest security exposure was the fact that most organizations have ZERO projection when a zero day is released [up until] when they can patch it. Even patching a Web Application Firewall (WAF) after a couple of days was bypassed. Organizations must protect their applications from these unknown risks through use of runtime protections. 

How well did organizations/industry/government respond?  

David Lindner: Many organizations spent weeks finding and fixing their Log4j libraries, especially with Log4j being patched four times over the course of two weeks as the vulnerability was fully unraveled in numerous scenarios. However, our data shows only 50% to this point have upgraded to a fully fixed version of Log4j, which means that many are still exposed to the potential for breach. 

Will attackers continue to target the flaw in 2023 … and beyond?

David Lindner: Given that the Log4j library is used in ~64% of Java applications, and that only 50% of those apps have updated to a fully fixed version, there’s no reason for attackers to stop targeting it. They’ll be able to successfully exploit the vulnerability in many cases. 

How can we determine if a given app hasn’t been updated to a fixed version?

David Lindner: The recent OMB-22-18 directive [PDF] is going to make it much more difficult for these organizations to hide their data about using vulnerable third-party components like Log4j, but at least for now, it’s still easy pickings for attackers looking to find paths to exploit through Log4j.

Click here for a demo of runtime protection with Contrast's Protect.