Log4j BlindSpots

Apache Java logging library log4j‘s popularity and its ability to hide in code,landmines hiding in infrastructure due to log4j’s Log4Shell security vulnerabilities. The good news is there are scanning tools that can find those vulnerable libraries before they go bang. The bad news is, that no single scanning tool can find all the security compromised programs.

The problem with detecting Log4Shell within packaged software in production environments is that Java code can be nested a few layers deep into other files. A simple shallow search for it can miss it entirely. Adding insult to injury, log4j can be packaged in many different formats such as Java Archive Files (JARs), Tape Archive (TAR), Web Application Archive (WAR), Enterprise Application Archive (EAR) Service Application Archive (SAR).Salting the wound Java code can be buried many levels down in these formats. It’s a real nightmare digging up the suspect code.

A survey has been conducted 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.

The big surprise is there is no single scanner that can spot examples of the problem code. Your only choice is to use multiple scanners.

Researchers found that while tools can detect vulnerable Log4j instances in multiple Java binaries types with a range of file extensions, sometimes the names are the ones we’re searching for. The ElasticSearch binary detection evaluation, the JAR name we examined was elastic-search-sqlcli-7.4.2.jar, a filename that does not meet the basic identification pattern used by many scanners to detect Log4j (e.g.: log4j-core-.jar), yet it still contained vulnerable pieces of Log4j code.”

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 most of the code in production. Code-level visibility in runtime memory where the code isn’t packaged or nested. Security leaders cannot blindly assume that various open-source or 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.

Log4j can be called by indirect or transitive dependencies that the direct dependencies are calling. The majority of affected artifacts stem from indirect, transitive dependencies. Log4j is not explicitly defined as dependency of the artifact, but gets pulled in as a transitive dependency. More than 80% of the packages, the vulnerability is deeper than one level down, with a majority affected five levels down.

The best Recommendation is using multiple approaches to find and patch the vulnerable code. The company is also, of course, willing to run a free assessment to quickly detect if you have undetected instances of Log4j and determine whether or not these instances are exploitable and require immediate action.