Log4j Blindspots: What Your Scanner Is Still Missing

By Yotam Perkal, Vulnerability Research Lead, Rezilion

The popularity of the Log4j library, coupled with the ease of exploitability and severe potential impact, means Log4Shell’s blast radius is enormous – that’s old news by now. However, what’s being revealed these last few days is not just how popular it is, but how deeply rooted it is in the software we use – and this depth is creating some unique challenges in detecting it. 

Detecting Log4Shell

The biggest challenge lies in detecting Log4Shell within packaged software in production environments: Java files (such as Log4j) can be nested a few layers deep into other files – which means that a shallow search for the file won’t find it. Furthermore, they may be packaged in many different formats which creates a real challenge in digging them inside other Java packages.

In order to estimate how big the industry’s current blindspot is Rezilion’s vulnerability research team conducted a survey where multiple open source and commercial scanning tools were assessed against a dataset of packaged Java files where Log4j was nested and packaged in various formats. All formats are commonly used by developers and IT teams. Some scanners did better than others, but none was able to detect all formats.

A summary of Rezilion’s initial analysis can be found in the table below.

Update: Following the publication of our findings, we were approached by several vendors (Jfrog, Anchore, and others), letting us know they have updated their tools and improved support for formats such as ZIP files and the PAR format. An updated view of the analysis table below reflects these changes.

Another alternative that was assessed is using source-code analysis in order to detect dependencies on Log4j. While this approach will effectively detect nested and packaged instances of the vulnerable component, it can’t be applied to packaged third party software (which still constitutes for most of the code in production). Furthermore, it has major blindspots and false-positives when it comes to transient dependencies – which we also discuss in the research.

Rezilion’s research demonstrates the limitations of static scanning in detecting Log4j instances, and highlights the need for code-level visibility in runtime memory where the code isn’t packaged or nested. It also reminds us that detection abilities are only as good as your detection method. Scanners have blindspots. Security leaders cannot blindly assume that various open source or even commercial-grade tools will be able to detect every edge case – and in the case of Log4j  there are a lot of edge instances in many places. Download the research now and learn where these blindspots may exist in your environment.

If your organization is interested building a dynamic SBOM to deepen visibility across your attack surface, Rezilion can help. Contact us today for a free assessment to quickly understand if you have undetected instances of Log4j across your environment and to know whether or not these instances are exploitable and require immediate action.

Update: Following the publication of our findings, we were approached by our friends at Jfrog letting us know they recently (December 24, 9:30 AM GMT+2) updated their tool and added support for ZIP files, as well as for the PAR format. The table has been updated to reflect these changes. Additionally, CrowdStrike’s CAST tool was also evaluated and results were added to the table.