The Log4j vulnerability tracked as CVE-2021-44228 (also known as Log4Shell) allows an attacker to execute arbitrary code in a system. If your application uses Log4j from version 2.0-alpha1 to 2.14.1, you should update to the latest version (2.16.0 at the time of writing this) as soon as possible.

The Swiss government published an excellent diagram that explains the vulnerability:

Now let’s dive into mitigation strategies...

Using the Maven Dependency Plugin

In a Maven project, you can search for the log4j-core dependency in the dependencies tree and check if you are using an affected dependency. An easy way to do this is by running the following command:

mvn dependency:tree -Dincludes=org.apache.logging.log4j:log4j-core

This command uses the Maven Dependency Plugin to show the dependency tree (including transitive dependencies) for the project. The includes option filters the output to show only the log4-core dependency. If your project depends on a vulnerable version of Log4j, you’ll see something like the following:

In this example, the output shows that the project directly uses version 2.14.1 (vulnerable) of Log4j. This project needs to update the dependency:

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.14.1</version> <!-- update this! -->
</dependency>

To the following:

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.16.0</version> <!-- or newer version -->
</dependency>

I tried this with the JDBC connector project for the MariaDB database and got the following:

This is good news – the project doesn’t use Log4j and hence it’s not vulnerable to Log4Shell (see this article with more information on the specific case of MariaDB).

Using the Maven Help Plugin

If you want to investigate further, you might want to inspect the effective POM and search for the logging framework used in your project. Continuing with the MariaDB JDBC connector project, I used the Maven Help Plugin to generate the effective POM and, since I was using a Unix-like operating system (macOS), I filtered the output using grep (you can use findstr in Windows) as follows:

mvn help:effective-pom | grep log

I got the following output:

This shows that the MariaDB JDBC driver uses Logback as a logging framework. Although Logback is not affected by Log4Shell, it has a related vulnerability (of much lesser severity, no need to panic) fixed in version 1.2.8 and 1.3.0-alpha11. I checked the version used by the connector and found that it used 1.3.0-alpha10. Even though Logback is included as a test dependency in the MariaDB driver, I sent a pull request on GitHub to update it. I encourage you to do the same in any open-source project you find and that includes a vulnerable dependency.

Using Syft and Grype

In more complex projects with a large number of JAR files, you can use tools such as Syft and Grype. Syft is a CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems. It can be used with Grype which scans container images and filesystems for vulnerabilities through multiple levels of nesting.

Using LunaSec’s Tool

The folks at LunaSec (an open-source data security platform) developed an open-source tool to scan directories and find files that have a matching hash to vulnerable Log4j dependencies. The tool is available for Windows, Linux, and macOS systems. All you have to do is run the tool passing the directory to scan. For example:

log4shell scan your-project-dir

In a vulnerable project, you’ll get something like the following:

10:04AM INF identified vulnerable path fileName=org/apache/logging/log4j/core/net/JndiManager$1.class path=test/struts-2.5.28-all/struts-2.5.28/apps/struts2-rest-showcase.war::WEB-INF/lib/log4j-core-2.12.1.jar versionInfo="log4j 2.8.2-2.12.0"

Using log4j-scan

The team at FullHunt provided an open-source tool called log4j-scan, an automated and extensive scanner for finding vulnerable Log4j hosts. It allows teams to scan their infrastructure but also test for WAF (Web Application Firewall) bypasses that can result in code execution. The tool has several options but in short, you pass to the tool the URL to scan and you get a report on the vulnerabilities found. For example:

python3 log4j-scan.py -u https://log4j.lab.secbot.local

Here’s a screenshot of the output:

Using the Huntress Log4Shell Vulnerability Tester

The Huntress Log4Shell vulnerability tester is an open-source tool available online that lets you check if an application uses a vulnerable version of Log4j. The tool generates a string that you can use as input in the application you want to check, for example by using it in a text field. This string includes a JNDI lookup to an LDAP server. The server logs requests from your app and shows the IP address from where the request originated. I recorded a video demonstrating this tool:

Conclusion

More tools are appearing and I recommend keeping an eye on what security experts are publishing. And just like I did with the MariaDB JDBC connector, I encourage you to send patches to any open-source project that uses Log4j if you find it uses a vulnerable version.

How to Check if a Java Project Depends on A Vulnerable Version of Log4j