Log4j Detection with JFrog OSS Scanning Tools

The discovery of the Log4Shell vulnerability in the ubiquitous Apache Log4j package is a singular event in terms of both its impact and severity. Over 1 million attack attempts exploiting the Log4Shell vulnerability were detected within days after it was exposed, and it may take years before we see its full impact.

While it’s hard to draw general lessons from such an extreme scenario, it provides an opportunity to gauge our existing software development, testing, and release methodologies, and consider what can be done differently in the future to prevent this scenario.

The Log4j vulnerability incident can also provide an opportunity to think over the challenges developers face when such major vulnerabilities are publicized, and consider which tools might help them deal with the situation more quickly and easily. Having a solid understanding of the actual problem at hand is key to choosing the right tool(s) needed to remedy the situation. In some cases, simple tools specifically designed for the task at hand will be more effective than complex universal tools.

After CVE-2021-44228 was publicized, the JFrog Security Research team quickly set to work on thoroughly investigating the vulnerability discovery so they could adequately assess how to best support the developer community. In addition to publishing our Log4Shell vulnerability research and recommendations,  we also designed and published a set of dedicated Log4j open-source scanning tools for developers to detect Log4j utilization and risk in both their source code and binaries. The tools are configurable and can easily be adapted by developers for their specific tasks.

In this blog post, we share the thought process and considerations that guided us when creating these Log4Shell scanning and detection tools.

The first decision we made was to create passive scanning tools. When surveying available tools published by others, we saw that many of them are active – they try to test for the existence of the vulnerability in the running services, or even patch the Log4Shell vulnerability, by exploiting it. We decided to keep to passive code and binary Log4j scanning tools for two reasons:

1. Triggering an exploit on a live system is an action that involves some risk and would not be desired by most developers or security practitioners
2. Active Log4j scanning tools attempt to trigger the Log4Shell vulnerability by entering inputs through user-accessible interfaces and seeing the results, without analyzing  the data path between the user-accessible interfaces and the potentially vulnerable logging API functions. Therefore, if all attempts at triggering the vulnerability fail, one may erroneously reach the conclusion that the application is safe even though the Log4j vulnerability is still exploitable by entering inputs that were not tested.

Another decision we made was not to rely on diagnosing potentially vulnerable packages using build dependencies. While this approach is clearly valuable, we decided that the severity of the Log4j vulnerability justifies looking deeper in order not to miss cases when build dependencies are wrong, due to direct inclusion of code not via package manager or other reasons.

Ultimately, we focused on two main tasks:

1. Using code classes to diagnose inclusion of vulnerable code from log4j-core, rather than specific file names or metadata. This tool is helpful for producing an unconditional answer to the question “does the running code include Log4j”, as it does not assume anything about the file names, or completeness of build info or vulnerable package databases.
2. Scanning for calls to the vulnerable code. These tools may help developers understand how Log4j is used in their application. While it is probably not the first thing they should do at the expense of actively patching the software, these scanning tools may enable the developer to quickly assess whether unfiltered user-controlled input may reach Log4j API calls, and to conclude whether the software was indeed vulnerable before the patch, or be used as an additional layer of verification.

As additional caveats and vulnerabilities are discovered, we are continuing to add Log4j scanning and detection tools to help developers verify the configuration and the mitigations in place, to gain a quick understanding of where they are vulnerable to the Log4Shell exploit.

Follow @jfrog on Twitter for ongoing Log4Shell updates.

Additional Resources:
Log4shell 0-Day vulnerability: All You Need to Know – Blog Post
Log4j Log4Shell Vulnerability Explained – Webinar
Log4j Log4Shell Vulnerability Q&A – Blog Post