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…