Free tool to detect Log4j components in your network infrastructure: Check if your servers are vulnerable

Exploiting vulnerabilities detected in previous versions of Log4j remains a severe issue, so the cybersecurity community is still looking for the best ways to prevent a cyberattack. However, some users do not know how to implement the necessary protections or even do not know if the vulnerable utility exists on their systems.

To do this, security specialists developed a tool capable of detecting almost any version of Log4j in the analyzed system, specifically the versions vulnerable to CVE-2021-44228 and CVE-2021-45046. This utility allows detecting vulnerable instances present in the deepest layers of the affected systems and is functional in Linux, Windows, Mac and any other Java executions.

The tool is open source and available through GitHub.

Using the tool

Let’s test the tool using the example parameters shown below:

java -jar log4j-detector-2021.12.17.jar [path-to-scan] > hits.txt

Possible scan results include:

java -jar log4j-detector-2021.12.17.jar ./samples 

-- v2021.12.17 (by analyzing paths (could take a while).
-- Note: specify the '--verbose' flag to have every file examined printed to STDERR.
/opt/mergebase/log4j-detector/samples/clt-1.0-SNAPSHOT.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/infinispan-embedded-query-8.2.12.Final.jar contains Log4J-2.x   >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/log4j-1.1.3.jar contains Log4J-1.x   <= 1.2.17 _OLD_ :-|
/opt/mergebase/log4j-detector/samples/log4j-1.2.13.jar contains Log4J-1.x   <= 1.2.17 _OLD_ :-|
/opt/mergebase/log4j-detector/samples/log4j-1.2.17.jar contains Log4J-1.x   <= 1.2.17 _OLD_ :-|
/opt/mergebase/log4j-de   tector/samples/log4j-core-2.0-beta2.jar contains Log4J-2.x   <= 2.0-beta8 _POTENTIALLY_SAFE_ :-| (or did you already remove JndiLookup.class?) 
/opt/mergebase/log4j-detector/samples/log4j-core-2.0-beta9.jar contains Log4J-2.x   >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/log4j-core-2.0.2.jar contains Log4J-2.x   >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/log4j-core-2.0.jar contains Log4J-2.x   >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/log4j-core-2.10.0.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/log4j-core-2.12.2.jar contains Log4J-2.x   >= 2.12.2 _SAFE_ :-)
/opt/mergebase/log4j-detector/samples/log4j-core-2.14.1.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/log4j-core-2.15.0.jar contains Log4J-2.x   >= 2.15.0 _OKAY_ :-|
/op   t/mergebase/log4j-detector/samples/log4j-core-2.16.0.jar contains Log4J-2.x   >= 2.16.0 _OKAY_ :-)
/opt/mergebase/log4j-detector/samples/log4j-core-2.17.0.jar contains Log4J-2.x   >= 2.16.0 _SAFE_ :-)
/opt/mergebase/log4j-detector/samples/log4j-core-2.4.1.jar contains Log4J-2.x   >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/log4j-core-2.9.1.jar contains Log4J-2.x   >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(

Interpret the results obtained

Below is a guide for system administrators to know exactly what the results released by the tool referring to:

  • _VULNERABLE_: You need to update or delete the file
  • _OKAY_: This result appears when you find Log4j versions such as 2.15.0 and 2.16.0. in this case we recommend that you upgrade to v2.17.0
  • _SAFE_: A result that only appears when you find Log4j v2.17.0 and v2.12.2
  • _OLD_: Your deployment is not vulnerable to CVE-2021-44228, but you should plan for the next update before new flaws appear
  • _POTENTIALLY_SAFE_: The JndiLookup.class file is not present, either because the system is running a very old version of Log4J or because someone has already deleted this file before. Be sure to verify that this item has been removed correctly to rule out malicious behavior

Many currently available scanners report that the “log4j-core” and “log4j-api” libraries are vulnerable. The scans are correct as there is currently no version of the “log4j-api” library that can be exploited by any of these vulnerabilities.

Developers believe that detailed reporting is necessary to create a complete security environment, so scanning isn’t just about reporting on the detection of a vulnerable version. Either way, the main security recommendation is to update Log4j to v2.17.0.

 Moreover, about the analysis result file1.war!/path/to/!/path/to/file3.jar!/path/to/log4j.jar, the developers mention that “!” means that the Log4j detector entered a ZIP file. Since these files may contain additional zip files, a single result may contain more than one “!” indicator in its result.

The main reason is that Java systems are often configured to run jar within jar, but are never configured to run other file formats. Therefore, a copy of Log4j within a *.tar.gz is probably not accessible to a running Java system and therefore not an exploitable vulnerability.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.