[ad_1]
Four months have passed since Log4Shell, a critical zero-day vulnerability in the ubiquitous Apache Log4j library, was discovered, and threat analysts warn that the application of available fixes is still long overdue.
Although the public interest and focus of the information security community has shifted to new vulnerabilities and exploits, Log4Shell remains a large-scale problem and serious security risk.
The last time we touched on Log4Shell exploitation was about two months ago when a Barracuda report highlighted that it was primarily exploited by botnets for DDoS and cryptocurrency mining.
However, a new report released today by Rezilion paints a dire picture, revealing a large attack surface across a wide range of software products.
This is a serious problem due to its potential impact (remote code execution) and ease of exploitation (PoC availability).
A problem that is still there
According to the Rezilion report, which presents data from multiple points, Log4Shell, tracked as CVE-2021-44228, is still present in so many software products that formulating a logical explanation is challenging.
For example, looking at Sonatype’s Log4j download dashboard, we see that a consistent percentage of almost 40% are still downloading vulnerable versions of Log4j, even as of the end of April.
While this was previously attributed to security researchers, analysts, or even threat actors testing their exploits, the percentage’s persistence at high levels after all this time rules out these scenarios.
Examining data from Google’s Open Source Insights service, Rezilion found that of the 17,840 open source packages that used Log4j as a dependency, only 7,140 had been upgraded to a fixed version. Therefore, 60% of them are still vulnerable to Log4Shell.
Searching for the particular category of open source containers on Shodan, Rezilion found over 90,000 potentially vulnerable Internet applications containing outdated versions of Log4j. A notable example is Apache Solr, which has 1,657 public implementations and still uses Log4j-core-2.16.0-jar.
Other popular containers patched with a massive delay in April 2022 are Apache Storm and Apache skywalking-oap, while WSO2 API Manager has been patched in March 2022.
Obviously, the latest container versions have not yet been adopted by all users, so there are still tens of thousands of vulnerable Internet-facing implementations.
Then there are those that use the deprecated and no longer supported Log4j 1.2.17, including Atlassian Crucible, Apache zeppelin, Bitnami Kafka, and Bitnami Spark. There is a misconception that Log4Shell does not affect the previous version branch, but this is not true.
Finally, by looking at the Minecraft servers, which is the point from where the Log4Shell discovery started, Rezilion discovered 68,000 potentially vulnerable servers.
a possible explanation
Rezilion suggests that the current state of patching is due to several contributing factors, including a lack of proper vulnerability management processes and poor visibility.
Log4j is difficult to detect in production environments and organizations don’t always realize they are using it through third-party software.
In short, companies don’t know if they’re using it, they don’t know which version they’re using, and they don’t know which versions are safe to use.
Then there are the various special cases, such as the use of granular software update policies in containerized environments that favor operational stability and do not pull the latest available software updates.
Old flaws persist
As CISA’s bulletins on active exploiting flaws have repeatedly highlighted, hackers don’t care how old a vulnerability is as long as it gets them to the target device.
We often see 10 year old bugs still being actively exploited in the wild, and Log4Shell seems like an excellent candidate to facilitate the continuation of this practice.
Four months after discovery and patching, Log4Shell is still around, so scan your environment, find which version you’re using, and then develop an emergency upgrade plan.
If you find that you were using a vulnerable version all this time, make the commitment and continue down that path to look for signs of malicious activity and remove any planted backdoors.
[ad_2]
