Log4j Shell CVE 2021 44228

There has been a huge surge on the Apache Log4J, a very popular and ubiquitous logging framework for the Java applications, which has recently had a hit due to a vulnerabilty on 09th Dec 2021. Let us talk about the same and the mitigation strategies in this post.

Origin

The look up feature of a JNDI, LDAP in the log4j message layout has actually opened the doors for the vulnerability in a chatting aplication and was found out by Chen Zhaojun of Alibaba Cloud Security Team. Please read this post as well - https://www.lunasec.io/docs/blog/log4j-zero-day/

Image Courtesy: GovCert.ch Website

Versions impacted

Log4j versions from 2.0 upto 2.14.1 was impacted and advised to follow any of the following fixes.

Fixes

• Permanent Fix : Upgrade to log4j 2.15.0 - as where they had disabled the look up of messages by default, and hence the people whoever actually uses this RCE (Remote Code Execution) have to manually enable them, while sparing the rest of the world who does NOT even use ths feature.
• Temporary Fix : Add a JVM Parameter - java -Dlog4j2.formatMsgNoLookups=true in the JVM while starting the server, which will disable the mesage look up feature.

This temporary fix is applicable only if you use the log4j version 2.5 to 2.13 or so. A lower version than 2.5, does not have option other than upgrading to log4j 2.15.0.

Extended Fix - Banned Dependencies

Apache Maven has a way to ban the dependencies of the JAR files if any could be brought by the indirect reference, with an element named bannedDependencies, which helps us to be rest assured of not getting the JARs of lower version that could potentially be vulnerable.

Sample - Banned Dependencies

The below code snippet taken from https://gist.github.com/gunnarmorling/8026d004776313ebfc65674202134e6d.

 <executions>
    <execution>
      <id>ban-bad-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>

Apache Log4j 2.15.0 - Fixes

An excerpt from the Apache Log4j Website for the fixes applied on the Log4j 2.15.0 version is given below.

Fixed in Log4j 2.15.0

CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints.

Severity: Critical

Base CVSS Score: 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Versions Affected: all versions from 2.0-beta9 to 2.14.1

Descripton: Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default.

Mitigation: In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. For releases from 2.7 through 2.14.1 all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m. For releases from 2.0-beta9 to 2.7, the only mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

Credit: This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team.

References: https://issues.apache.org/jira/browse/LOG4J2-3201 and https://issues.apache.org/jira/browse/LOG4J2-3198.

Zero Day

The reason why it is called as Zero day is because there was no patch/fix available on the same day it was reported.

Spring Boot Users

A good news to the Spring Boot users is that Spring Boot by default uses logback as the logging framework (yet another flavor of log4j, written by the same authors).

Check these links :

• https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot
• https://www.educba.com/log4j-vs-logback/

References

• https://www.lunasec.io/docs/blog/log4j-zero-day/
• https://thehackernews.com/2021/12/extremely-critical-log4j-vulnerability.html
• https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/
• https://logging.apache.org/log4j/2.x/security.html
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
• https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/?s=09
• https://nvd.nist.gov/vuln/detail/CVE-2021-44228
• https://www.infoworld.com/article/3644492/how-to-detect-the-log4j-vulnerability-in-your-applications.html
• https://indianexpress.com/article/technology/tech-news-technology/log4j-vulnerability-log4shell-responses-of-top-companies-google-microsoft-cisco-amazon-7670668/
• http://slf4j.org/log4shell.html
• https://github.com/cn-panda/logbackRceDemo

Cheers,
RM…
Raghavan alias Saravanan Muthu
13 Dec 2021 | Mon | 19:52:37 PM IST