By Lisa Vaas, Senior Content Marketing Manager, Contrast Security
December 8, 2022
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.
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.
David Lindner: Log4j exposed many things when it comes to security issues:
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.
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.
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.
Lisa Vaas is a content machine, having spent years churning out reporting and analysis on information security and other flavors of technology. She’s now keeping the content engines revved to help keep secure code flowing at Contrast Security.
Get the latest content from Contrast directly to your mailbox. By subscribing, you will stay up to date with all the latest and greatest from Contrast.