Public interest in Log4Shell fades but attack surface remains

It’s been four months since Log4Shell, a critical zero-day vulnerability in the ubiquitous Apache Log4j library, was discovered, and threat analysts warn that the application of the available fixes is still way behind.

Although the public interest and focus of the infosec community have moved to newer vulnerabilities and exploits, Log4Shell continues to be a large-scale problem and a grave security risk.

The last time we touched the subject of Log4Shell exploitation was roughly two months ago when a Barracuda report highlighted that it was primarily botnets that leveraged it for DDoS and cryptocurrency mining.

However, a new report published today by Rezilion paints a dire picture, revealing a large attack surface across a wide range of software products.

This is a severe problem due to its potential impact (remote code execution) and the ease of exploitation (availability of PoCs).

A problem that’s still there

According to Rezilion’s report, which presents data from various points, Log4Shell, tracked as CVE-2021-44228, is still present in so many software products that formulating a logical explanation is challenging.

For example, when looking into Sonatype’s Log4j Download Dashboard, we see that a steady percentage of almost 40% is still downloading vulnerable Log4j versions even at the end of April.

While this was previously attributed to security researchers, analysts, or even threat actors testing their exploits, the persistence of the percentage on high levels after all this time excludes these scenarios.

When looking into data from Google’s Open Source Insights service, Rezilion found that out of the 17,840 open-source packages using Log4j as a dependency, only 7,140 had upgraded to a fixed version. Hence, 60% of them remain vulnerable to Log4Shell.

When searching for the particular category of open-source containers on Shodan, Rezilion found over 90,000 potentially vulnerable internet-facing apps that contain obsolete versions of Log4j. A notable example is Apache Solr, counting 1,657 public deployments and still using 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 the WSO2 API Manager was patched in March 2022.

Obviously, the latest container versions haven’t been adopted by all users yet, so there are still tens of thousands of vulnerable internet-facing deployments.

Then there are those using the obsolete and no longer supported Log4j 1.2.17, including Atlassian Crucible, Apache zeppelin, Bitnami Kafka, and Bitnami Spark. There’s a misconception that Log4Shell does not impact the older version branch, but this is not true.

Finally, when looking at 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 today’s patching state results from several factors that contribute to the problem, 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’re using it through third-party software.

In summary, companies don’t know if they’re using it, don’t know which version they use, and don’t know which versions are safe to use.

Then there are the various special cases like using granular software update policies on containerized environments that favor operational stability and don’t pull the latest available software updates.

Old flaws persist

As CISA’s bulletins on the active exploitation of flaws have repeatedly highlighted, hackers don’t care about the age of a vulnerability as long as it gets them into a targeted device.

It is often the case that we see 10-year-old bugs still actively exploited in the wild, and Log4Shell looks like an excellent candidate for facilitating the continuation of this practice.

Four months after discovery and patching, Log4Shell is still present, 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, assume compromise and continue on that pathway to scan for signs of malicious activity and uproot any planted backdoors.