Nearly 4,000 businesses globally are still vulnerable to Log4j exploits two years on from the devastating attack, according to new research.
Analysis from Veracode found 38,278 unique applications operating Log4j versions 1.1 through to 3.0.0-alpha1 across 3,866 different organizations.
Of the exposed Log4j iterations, 2.8% of the applications were using versions with the original Log4Shell vulnerability that saw nearly one million exploit attempts made in the first three days after it was disclosed on 9 December 2021.
A further 3.8% of applications were running Log4j 2.17.0 that was patched to remove the Log4Shell exploit but still contains the vulnerability that allows attackers to deploy remote control exploits (RCEs), the study found.
Veracode speculated the prevalence of at-risk applications running 2.17.0 is due to teams quickly acting to patch the initial Log4Shell vulnerability but failing to remain vigilant and patch their software after this point.
Additionally, around 32% of applications were found to be using Log4j2 1.2x, which reached end-of-life (EOL) in August 2015 and is no longer receiving security updates.
Apache disclosed three critical vulnerabilities affecting Log4j 1.2x in January 2022, taking its total number of critical vulnerabilities since it reached EOL to seven.
What is Log4Shell?
The Log4Shell vulnerability directly impacted the highly-popular Java logger, Log4j, in December 2021. The incident sent shockwaves throughout the global cyber security industry, with organizations around the world scrambling to patch the flaw.
Tracked as CVE-2021-44228, Log4Shell was given a 10/10 critical rating and was immediately pounced upon by threat actors, including cryptominers.
Nearly one million exploit attempts were recorded within just days of disclosure.
Organizations are not aware of the risks open source libraries bring
Open source libraries are becoming ubiquitous in many applications, with previous research by Veracode showing the average Java application is composed of 97% third-party code.
The new findings from Veracode revealed developers never update third–party libraries after adding them to a codebase 79% of the time, explaining why so many applications are still using vulnerable versions of the logging utility.
The failure to regularly update their version of Log4j is particularly puzzling as 65% of open source library updates are minor changes and unlikely to significantly affect the functionality of most applications.
Discover why current security approaches might not be working
DOWNLOAD NOW
The research does show developers are relatively quick to act once they are aware of a vulnerable library. For example, 50% of vulnerabilities are fixed within 89 days of being detected, and in 65 days for high severity vulnerabilities.
Developers are constrained by insufficient information and resources, however, according to the report. Veracode found developers who were lacking adequate resources took 13.7 times longer to fix half of the vulnerabilities.
Similarly, developers missing the required context for a vulnerability take over seven months to address half of their vulnerability backlog.
