Roughly 38% of applications using the Apache Log4j library are using a version vulnerable to security issues, including Log4Shell, a critical vulnerability identified as CVE-2021-44228 that carries the maximum severity rating, despite patches being available for more than two years.
Log4Shell is an unauthenticated remote code execution (RCE) flaw that allows taking complete control over systems with Log4j 2.0-beta9 and up to 2.15.0.
The flaw was discovered as an actively exploited zero-day on December 10, 2021, and its widespread impact, ease of exploitation, and massive security implications acted as an open invitation to threat actors.
The circumstance prompted an extensive campaign to notify affected project maintainers and system administrators, but despite numerous warnings, a significant number of organizations continued to use vulnerable versions long after patches became available.
Two years after the vulnerability was disclosed and fixes were released, there are plenty of targets still vulnerable to Log4Shell.
A report from application security company Veracode, based on data collected between August 15 and November 15, highlights that old problems can persist for an extensive periods.
Solidified attack surface
Veracode gathered data for 90 days from 3,866 organizations that use 38,278 applications relying on Log4j with versions between 1.1 and 3.0.0-alpha1.
Of those apps, 2.8% use Log4J variants 2.0-beta9 through 2.15.0, which are directly vulnerable to Log4Shell .
Another 3.8% use Log4j 2.17.0, which, although not vulnerable to Log4Shell, is susceptible to CVE-2021-44832, a remote code execution flaw that was fixed in version 2.17.1 of the framework.
Finally, 32% are using Log4j version 1.2.x, which has reached the end of support since August 2015. Those versions are vulnerable to multiple severe vulnerabilities published until 2022, including CVE-2022-23307, CVE-2022-23305, and CVE-2022-23302.
In total, Veracode found that about 38% of the apps within its visibility use an insecure Log4j version.
This is close to what software supply chain management experts at Sonatype report on their Log4j dashboard, where 25% of the library’s downloads in the past week concern vulnerable versions.
Bad security practices
The continual use of outdated library versions indicates an ongoing problem, which Veracode attributes to developers wanting to avoid unnecessary complications.
According to Veracode’s findings, 79% of developers opt never to update third-party libraries after their initial inclusion in their code base to avoid breaking functionality.
This is true even if 65% of open-source library updates contain minor changes and fixes unlikely to cause functional problems.
Moreover, the study showed that it takes 50% of projects over 65 days to address high-severity flaws. It takes 13.7 times longer than usual to fix half of what’s in their backlog when understaffed and over seven months to handle 50% of it when lacking information.
Unfortunately, Veracode’s data shows that Log4Shell has not been the wake-up call many in the security industry hoped it would be.
Instead, Log4j alone continues to be a source of risk in 1 out of 3 cases and may very easily be one of the multiple ways attackers can leverage to compromise a given target.
The recommendation for companies is to scan their environment, find the versions of open-source libraries in use, and then develop an emergency upgrade plan for all of them.
Comments
h_b_s - 4 months ago
What a lot of these so-called security companies won't tell you, because it undermines some of their rhetoric and income stream, is just because a product has a dependency on a library with a particular vulnerability doesn't necessarily mean the application shares the vulnerability. It's entirely possible for the library vulnerability to be irrelevant in practice because the application never uses the vulnerable calls. That means the code never gets loaded, hence the application isn't vulnerable.
Just because those sites have vulnerable versions of Log4j doesn't always follow they're also vulnerable. It's possible to patch it on the fly. It's also possible those code paths aren't used. I've no doubt at least some of them are vulnerable to the CVE. I would be surprised however, if some of those supposedly vulnerable instances are merely using patches that were backported in without changing anything else - as is often the case with always-on infrastructure.