Researchers have found millions of Java applications still vulnerable in the wild to the infamous Log4Shell vulnerability CVE-2021-44228, more than four months after the severe flaw was discovered.
Late last year, researchers had previously discovered the Critical Log4Shell vulnerability (CVE-2021-44228) in Apache Log4j logging utility that can result in remote code execution (RCE) by logging a certain string. Multiple other Log4j vulnerabilities were subsequently found in the weeks that followed.
Rezilion researchers released a new report on the current threat landscape of the log4j vulnerability.
“We learned that the landscape is far from ideal and many applications vulnerable to Log4Shell still exist in the wild,” the security firm wrote in a blog post.
To back up the findings, the researchers first pointed to Google’s Open Source Insights, that has scanned millions of open source packages. As a result, nearly 60% of packages affected by the Log4Shell vulnerability have not been patched for the same issue. This also equates to almost 4% of the entire ecosystem of packages.
Moreover, Sonatype maintains a Log4j vulnerability resource center that shows 36% of the Log4j versions actively downloaded from Maven Central are still vulnerable to Log4j as of April 29, 2022 (see Figure A).
As revealed in the Rezilion report, finding Log4j vulnerabilities in open source packages can also be a difficult task. For instance, Java files can be “nested a few layers deep into other files — which means that a shallow search for the file won’t find it.”
The Rezilion team analyzed 90,000 potential vulnerable internet facing applications and found versions of containers that were still vulnerable to Log4j vulnerabilities CVE-2021-45406 or CVE-2021-45105. In other cases, the containers were running up-to-date versions, but there was still evidence of previous versions usage vulnerable to CVE-2021-44228.
Akamai also wrote about the Log4j threat affecting internal systems, not just external-facing systems, in a blog post:
“Note, however, that data centers where all Java servers are internal (namely, not internet-facing) cannot be considered safe. While Log4Shell has been mainly perceived as a means to breach networks, some cases showed how Java applications running on internal servers received logs from internet-facing servers and ended up being compromised. Log4Shell can thus be used as easily for lateral movement as for initial breach.”
Earlier this month, researchers from FortiLabs had detected a new cyber campaign involving Chinese Advanced Persistent Threat (APT) group Deep Panda that has exploited the Log4Shell vulnerability CVE-2021-44228 on vulnerable VMware Horizon servers to install digitally signed Fire Chili rootkits.