Two Years On, 1 In 4 Apps Still Vulnerable To Log4Shell

Two years after the Log4Shell vulnerability in the open source Java-based Log4j logging utility was disclosed, circa one in four applications are dependent on outdated libraries, leaving them open to exploitation.

Research from security shop Veracode revealed that the vast majority of vulnerable apps may never have updated the Log4j library after it was implemented by developers as 32 percent were running pre-2015 EOL versions.

Prior investigations from Veracode also showed that 79 percent of all developers never update third-party libraries after first introducing them into projects, and given that Log4j2 – the specific version of Log4j affected by the vulnerability – dates back to 2014, this could explain the large proportion of unpatched apps.

A far smaller minority are running versions that were vulnerable at the time of the Log4j vulnerability’s disclosure in December 2021. Only 2.8 percent are still using versions 2.0-beta9 through 2.15.0 – post-EOL versions that remain exposed to Log4Shell, the industry-coined moniker of the vulnerability’s exploit.

Some 3.8 percent are still running version 2.17, a post-patch version of the Java logger that’s not exposed to Log4Shell attacks, but is vulnerable to a separate remote code execution (RCE) bug (CVE-2021-44832).

The researchers believe this illustrates a minority of developers that acted quickly when the vulnerability was first disclosed, as was the advice at the time, had returned to older habits of leaving libraries untouched.

Altogether, just shy of 35 percent remain vulnerable to Log4Shell, and nearly 40 percent are vulnerable to RCE flaws.

The EOL versions of Log4j are also vulnerable to three additional critical bugs announced by Apache, bringing the total to seven high and critical-rated issues.

“At a surface level, the numbers above show that the massive effort to remediate the Log4Shell vulnerability was effective in mitigating risk of exploitation of the zero-day vulnerability. That should not be surprising,” said Chris Eng, chief research officer at Veracode.

“The bigger story at the two-year anniversary, however, is that there is still room for improvement when it comes to open source software security. If Log4Shell was another example in a long series of wake-up calls to adopt more stringent open source security practices, the fact that more than one in three applications currently run vulnerable versions of Log4j shows there is more work to do.

“The major takeaway here is that organizations may not be aware of how much open source security risk they are exposed to and how to mitigate it.”

The larger issue at play isn’t just the failure to apply patches. According to Sonatype, the number of Log4j downloads containing vulnerable versions just in the last seven days stands at 26 percent of a total 3.7 million.

It’s a phenomenon that hasn’t changed much since Log4Shell’s disclosure either, with 26 percent of all downloads since December 2021 vulnerable to the RCE exploit.

When it was first revealed, the vulnerability in Log4j catalyzed widespread fear in the infosec community, given its critical nature and the number of organizations whose software relied on it – a figure Veracode believed to have been around 88 percent at the time.

The predictions were that the bug was so dangerous, so exploitable, and so serious that it would haunt the industry for many months into 2022, and others like the US Department of Homeland Security speculated it could linger for longer than a decade. 

The director at the US Cybersecurity and Infrastructure Security Agency (CISA) said at the time it was the “most serious” vulnerability she had seen in her career.

However, fast action and urgent awareness campaigns ultimately meant the damage wasn’t as intense as many first feared.

Log4Shell did cause some high-profile issues, though, such as an attack on a US government network at the hands of Iranian state-sponsored cybercriminals, and the Belgian defense ministry mere weeks into the furore.

Though most organizations patched to secure versions within weeks rather than dealing with exploits, often the biggest pain felt was the patching process itself, which could have involved hundreds of apps, depending on the organization. ®

READ MORE HERE