After two years, Log4Shell is still a problem, as many projects are still vulnerable

log4j

Log4Shell is one to appear in data breaches over the next decade

This last month of the year 2023 marked the second anniversary of the discovery of the Log4j/Log4Shell vulnerability, which is a vulnerability that continues to affect many projects today and poses a security risk.

And Log4j continues to be a prime target for cyberattacks, according to Cloudflare's annual "Year in Review" report and also the results of a study on the relevance of critical vulnerabilities in the Log4j Java library released by security researchers. by Veracode.

The Veracode researchers mention that after studying 38.278 applications used by 3.866 organizations, they discovered that two out of five applications still use vulnerable versions of the Apache Log4j library, two years after a critical vulnerability was made public.

The report highlights that about a third of applications run Log4j2 1.2.x (which reached end of life in August 2015 and no longer receives patch updates) which represents 38%. The main reason for continuing to use legacy code is the integration of old libraries into projects or the laboriousness of migrating from unsupported branches to new branches that are backward compatible. In addition, 2.8% of applications still use versions vulnerable to the well-known Log4Shell vulnerability.

In addition to that, It is mentioned that there are three main categories of applications still using vulnerable versions of Log4j, according to the Veracode report:

  1. Log4Shell Vulnerability (CVE-2021-44228):
    2.8% of applications continue to use Log4j versions from 2.0-beta9 to 2.15.0, which contain the known vulnerability.
  2. Remote Code Execution (RCE) Vulnerability (CVE-2021-44832):
    3.8% of applications use the Log4j2 2.17.0 version, which addresses the Log4Shell vulnerability, but does not resolve the remote code execution (RCE) vulnerability identified as CVE-2021-44832.
  3. Log4j2 1.2.x Branch (Support Completed in 2015):
    32% of applications still use the Log4j2 1.2.x branch, whose support ended in 2015. This branch has been affected by critical vulnerabilities, such as CVE-2022-23307, CVE-2022-23305 and CVE-2022-23302, identified in 2022, seven years after the maintenance ended.

This data highlights the diversity of situations in which applications continue to use outdated and vulnerable versions of Log4j, raising significant concern from researchers.

And a worrying fact is that 3.8% of applications use Log4j2 2.17.0, which was patched against Log4Shell, but contains CVE-2021-44832, another high-severity remote code execution vulnerability.

The report highlights that, despite the efforts made in recent years to improve security practices in software development and the use of open source, there is work to do.

Chris Eng, research director at Veracode, highlights that:

Developers have a crucial responsibility and there is room for improvement when it comes to the security of open source software.

Although many developers initially responded appropriately to the Log4j crisis by installing version 2.17.0, the report suggests that some reverted to previous patterns by not applying patches beyond the release of 2.17.1.

The Apache Software Foundation (ASF) has been actively notifying downstream projects of the urgency to update, but the report's findings indicate that there are still applications that have not implemented the necessary fixes.

Veracode's report was based on data from software scans of more than 38,000 apps over a 90-day period between August 15 and November 15. The applications were running Log4j versions from 1.1 to 3.0.0 alpha 1 in 3,866 different organizations.

Our research also found that once developers are alerted to a vulnerable library through a scan, they fix them relatively quickly: 50 percent of vulnerabilities are fixed in 89 days overall, in 65 days for severity vulnerabilities high and in 107 days for medium severity vulnerabilities.

These results are consistent with previous warnings, such as the 2022 Federal Cybersecurity Review Board report, which indicated that the Log4j crisis would take years to fully resolve.

finally if you are interested in knowing more about it, I invite you to visit the original article on the veracode blog. The link is this.


Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: AB Internet Networks 2008 SL
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.