About 38% of applications using Apache Log4j integrate a vulnerable version of the library, including Log4Shell, a critical flaw identified as CVE-2021-44228, with a maximum severity rating in the Common Vulnerability Scoring System (CVSS), despite patches have been available for more than two years.
Log4Shell is an unauthenticated remote code execution (RCE) flaw that allows an attacker to take full control over systems based on 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 operators. This led to an extensive campaign to notify affected project maintainers and system administrators, but despite numerous warnings, a significant number of organizations continue to use vulnerable versions long after patches have become available.
Two years after the vulnerability was disclosed and fixes were released, there are many targets still vulnerable to Log4Shell. A report from application security company Veracode, based on data collected between August 15 and November 15 this year, highlights that old problems can persist for long periods.
Veracode gathered data for 90 days from 3,866 organizations using 38,278 applications that rely on Log4j with versions between 1.1 and 3.0.0-alpha1. Of these applications, 2.8% use the Log4J 2.0-beta9 to 2.15.0 variants, which are directly vulnerable to Log4Shell. Another 3.8% use Log4j 2.17.0, which, while not vulnerable to Log4Shell, is susceptible to CVE-2021-44832, a remote code execution flaw that was fixed in version 2.17.1.
Finally, 32% are using version 1.2.x of Log4j, which reached end of support in August 2015. These versions are vulnerable to several serious vulnerabilities published through 2022, including CVE-2022-23307, CVE-2022-23305 and CVE-2022-23302. In total, Veracode found that about 38% of applications within its visibility use an insecure version of Log4j.
The continued use of outdated versions of the library indicates an ongoing problem, which the company blames on developers wanting to avoid unnecessary complications.
According to Veracode’s findings, 79% of developers choose to never update third-party libraries after their initial inclusion in their codebase to avoid breaking functionality. This is despite the fact that 65% of open source library updates contain minor changes and fixes that are unlikely to cause functional problems.
Furthermore, the study showed that 50% of projects take more than 65 days to resolve high-severity failures. That is, 13.7 times longer than normal to fix half of what is on the security director’s to-do list when there is a lack of personnel and more than seven months to deal with 50% of that when there is a lack of information.
Unfortunately, Veracode’s data shows that Log4Shell was not the wake-up call that many in the security industry hoped it would be. Instead, Log4j alone remains a source of risk in one in three cases and could very easily be one of several ways that attackers can leverage to compromise a given target.
The recommendation for companies is to scan their environment, find the open source library versions in use, and then develop an emergency upgrade plan for all of them.
Sources: CisoAdvisor, Veracode
