This article was contributed by Ariel Assaraf, CEO of Coralogix 

Log4j2 is one of the most ubiquitous libraries in the JVM ecosystem. It regularly appears in libraries and frameworks, like Spring, are a necessary dependency. This fact only makes the recent discovery of a zero-day vulnerability in the Log4j2 library all the more terrifying. So, let’s discuss the Log4j2 vulnerability and how to tell if your Gradle or Maven applications are exposed.

What is the Log4j2 vulnerability, and how serious is it?

The vulnerability, CVE-2021-44228, is a remote code execution bug that allows users to control the contents of log messages to execute whatever code they like. This may seem a little niche at first, especially since users may not have access to the logs, but this points to a very dangerous attack vector.

Suppose your application logs some unsanitized input from the user, for example, the contents of a payload or a username. In that case, that is an attack vector that may be able to exploit this command, since the user can input arbitrary code into the logs. It is very common for applications to log user input, which is quite dangerous.

How do you know if you’re vulnerable?

There are a few ways that the Log4j2 vulnerability can pose a danger to your company.

• If your in-house software depends on Log4j 2.14.1 or less

• If a software-as-a-service (SaaS) provider you use depends on Log4j 2.14.1 or less

• If another partner of yours with access to your system depends on Log4j 2.14.1 or less

You can only really take action on the first item, as you can imagine. The other two are equally important, though. For example, if you use Cloudflare, you may be exposed, but all is not lost. So how can you take action with your applications?

Detecting the vulnerable version in Maven

Maven is one of the two most popular dependency and build management tools. Maven comes with many convenient tools that will enable you to generate what is known as a dependency tree. This tree represents all the dependencies that your application relies on.

Why can’t I just look in my dependency file?

Your dependency file shows all of the dependencies that your application directly relies on. However, these dependencies will also have their own dependencies. These are known as transitive dependencies. There are usually far, far more transitive dependencies than direct dependencies. If you rely only on your direct dependencies, you’re getting a fraction of the actual picture, and that isn’t enough to effectively identify the Log4j2 vulnerability and tackle this bug. So, how do you generate a dependency tree to get the complete picture of your software?

Create a dependency tree in Maven

The maven toolkit comes with a dependency plugin with a series of different commands to help you manage your dependencies and make informed choices. To install this plugin, you simply need to add it into the pom.xml of the application you’re looking to search through. You can check the usage section on the Maven site for how to install it.

Once you’ve done that, it’s simply a case of running a basic command from the root of your application code:

mvn dependency:tree

This will output the full dependency tree for your application and let you see what you’re relying on. However, you’re quickly going to notice that there is a lot of data to work through here. Fortunately, the dependency plugin allows you to filter this tree to find what you’re looking for.

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

This will allow you to see if any dependencies on your classpath have come from Log4j. You can zoom in on the specific libraries that need to change. Using this technique, you can easily scrape through many applications, gather a report of your vulnerable apps, and get moving.

What about Gradle?

Yes, of course! Gradle supports this with a slightly different syntax, but the outcome is very similar.

gradle -q dependencyInsight --dependency org.apache.logging.log4j 
 --configuration scm

This will tell you all the dependencies that belong to the Log4j group. This single command will only output if you have any dependencies on log4j. If you have no dependencies, you’ll likely see an empty tree. This is because you’ve added the dependency filter. If you’d like to view your full dependency tree (perhaps to sense-check the output), you can remove the — dependency switch.

What can you do once you’ve found it?

Vendors are rushing to release new versions of their libraries that depend on the latest version of Log4j2, which comes packaged with a fix for this vulnerability. Upgrading to those versions will close the attack vector.

So what version should you utilize?

The zero-day vulnerability was originally detected in version 2.14 of the Log4j2 library. Anything past this will reduce your exposure to malicious agents. However, a new vulnerability has been detected that impacts 2.15 and so version 2.16 is the correct version to jump to. This new vulnerability has a lower CVE score, 3.7, so it is less of a high priority, but still a concern. So jump to 2.16 and avoid the rubble.

However, before you race off and begin patching, try to get an understanding of the scope here. A measured, data-driven response is the best way forward. Understand your most serious vulnerabilities first, and then work your way down. With a measured, systematic approach, you will close this bug in no time.

Ariel Assaraf is CEO of Coralogix