How to Check if a Java Project Depends on A Vulnerable Version of Log4j
Tags: java, security, log4j, log4shell
Published: 2021-12-20 09:29:07

The [Log4j](https://logging.apache.org/log4j/2.x) vulnerability tracked as [CVE-2021-44228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228) (also known as [Log4Shell](https://en.wikipedia.org/wiki/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](https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core) (`2.16.0` at the time of writing this) as soon as possible.

The Swiss government [published](https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/) an excellent diagram that explains the vulnerability:

![The log4j JNDI Attack Vulnerability Diagram From the Swiss Government](https://dz2cdn1.dzone.com/storage/temp/15473108-04-log4j-attack.jpeg)

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](https://maven.apache.org/plugins/maven-dependency-plugin/index.html) 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:

![Vulnerable Code Example With Highlight](https://dz2cdn1.dzone.com/storage/temp/15473109-01-maven-output-vulnerable.png)

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:

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

To the following:

```XML
<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](https://mariadb.com/kb/en/about-mariadb-connector-j) project for the [MariaDB database](https://mariadb.com) and got the following:

![Test With MariaDB JDBC Connector](https://dz2cdn1.dzone.com/storage/temp/15473110-02-mariadb-jdbc-connector.png)

This is good news – the project doesn’t use Log4j and hence it’s not vulnerable to Log4Shell (see [this article](https://dzone.com/articles/is-the-mariadb-jdbc-driver-affected-by-the-log4j-v) 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](https://maven.apache.org/plugins/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:

![Output From mvn help](https://dz2cdn1.dzone.com/storage/temp/15473111-03-mariadb-logback.png)

This shows that the MariaDB JDBC driver uses [Logback](http://logback.qos.ch) 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`](http://mailman.qos.ch/pipermail/logback-user/2021-December/005168.html) 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](https://github.com/mariadb-corporation/mariadb-connector-j/pull/176) 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](https://github.com/anchore/syft) and [Grype](https://github.com/anchore/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](https://www.lunasec.io/) (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](https://github.com/lunasec-io/lunasec/releases/tag/v1.0.0-log4shell) 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](https://fullhunt.io/) provided an open-source tool called [log4j-scan](https://github.com/fullhunt/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](https://owasp.org/www-community/attacks/SQL_Injection_Bypassing_WAF) 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:

![Output From Using log4j-scan from FullHunt](https://dz2cdn1.dzone.com/storage/temp/15473112-0-5-log4j-scan.png)

Using the Huntress Log4Shell Vulnerability Tester
-------------------------------------------------

The [Huntress Log4Shell vulnerability tester](https://log4shell.huntress.com) 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](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228). And just like I did with the [MariaDB JDBC connector](https://mariadb.com/kb/en/mariadb-connector-j), I encourage you to send patches to any open-source project that uses Log4j if you find it uses a vulnerable version.