CVE-2021-44228 - Log4j 2 Vulnerability Analysis

Last Update: 4:13pm EST, Dec. 14, 2021 (List of updates at bottom)

What is Log4Shell?

Log4Shell is a high severity vulnerability (CVE-2021-44228, CVSSv3 10.0) impacting multiple versions of the Apache Log4j 2 utility. It was disclosed publicly via the project’s GitHub on December 9, 2021. This vulnerability, which was discovered by Chen Zhaojun of Alibaba Cloud Security Team, impacts Apache Log4j 2 versions 2.0 to 2.14.1.

The vulnerability allows for unauthenticated remote code execution. Log4j 2 is an open source Java logging library developed by the Apache Foundation. Log4j 2 is widely used in many applications and is present, as a dependency, in many services. These include enterprise applications as well as numerous cloud services.

There have been a flurry of new versions of Log4j that have been released to address this and similar vulnerabilities. Initially, Log4j version 2.15.0 was released to remediate CVE-2021-44228. Shortly thereafter, it was discovered that the patch was not sufficient to protect against attacks in certain non-default configurations. Log4j version 2.16.0 was then released to mitigate this development and a new designator, CVE-2021-45046, was assigned for the vulnerability. At first, the issue was rated a CVSS 3.7 as the impact was determined to be a denial of service only. Not long after, the issue was upgraded to a CVSS 9.0 due to researchers demonstrating it could be leveraged for remote code execution.

Most recently, Log4j version 2.17.0 has come out to address CVE-2021-45105, a denial-of-service vulnerability in the interpretation of JNDI lookups.

Initially, there were mixed reports (GitHub, Original Post) as to the susceptibility of Log4j 1.x. At this time, CVE-2021-4101 has been designated for the impact to Log4j 1.x. According to RedHat, remote code execution is possible for some non-default configurations of software running Log4j 1.x. Research by the security community into the extent of the impact on Log4j 1.x area is ongoing.

The Randori Attack Team has developed a working exploit and has been able to successfully leverage this vulnerability in customer environments as part of our offensive security platform.

The vulnerability is reachable via a multitude of application specific methods. Effectively, any scenario that allows a remote connection to supply arbitrary data that is written to log files by an application utilizing the Log4j library is susceptible to exploitation. This vulnerability is being exploited in the wild and thousands of organizations are impacted. This vulnerability poses a significant and active real world risk to affected systems – PLEASE TAKE IMMEDIATE ACTION.

In analyzing CVE-2021-44228, Randori has determined the following:

Default installations of widely used enterprise software are vulnerable.
The vulnerability can be exploited reliably and without authentication.
The vulnerability affects multiple versions of Log4j 2.
The vulnerability allows for remote code execution as the user running the application that utilizes the library.
Upgrading the underlying version of Java alone is insufficient to prevent exploitation of the vulnerability.

This is an evolving situation, if you need help – please reach out. Due to the severity of this issue, Randori is offering any enterprise a free Log4j attack surface review . We are committed to helping the community not only understand but respond quickly to this situation.

Impact

The Log4j 2 library is very frequently used in enterprise Java software. Due to this deployment methodology, the impact is difficult to quantify. Similarly to other high-profile vulnerabilities such as Heartbleed and Shellshock, we believe there will be an increasing number of vulnerable products discovered in the weeks to come.

Due to the ease of exploitation and the breadth of applicability, we suspect ransomware actors to begin leveraging this vulnerability immediately.

Recommendation

Randori encourages all organizations to adopt an assumed breach mentality and review logs for impacted applications for unusual activity.

If you find these hashes in your software inventory then you have the vulnerable log4j library in your systems and need to take action: https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes

If anomalies are found, we encourage you to assume this is an active incident, that you have been compromised and respond accordingly.

Upgrading to the patched versions of Log4j 2 or impacted applications will eliminate this vulnerability. Randori recommends any organization that believes they may be impacted to update to a patched version urgently.

In the latest update from the Apache Log4j team, they recommend organizations do the following:

Upgrade to Log4j 2.17.0.
- For those who cannot upgrade to 2.17.0: In any release less than 2.16.0, you may remove the JndiLookup class from the classpath:

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

If patching is not possible, it is highly advised organizations apply the temporary mitigation below and monitor impacted applications closely for anomalous behavior.

The presence of JAR files belonging to the log4j library can indicate an application is potentially susceptible to CVE-2021-44228. The specific files to search for should match the following following pattern:

log4j-core-*.jar;

Depending on the installation method, the location of the matching JAR file may also give indications as to which application is potentially vulnerable. For example, on Windows, if the file is located in C:\Program Files\ApplicationName\log4j-core-version.jar it indicates ApplicationName should be investigated. On Linux, the lsof utility can show which processes currently have the JAR file in use and can be run via the following syntax:

lsof /path/to/log4j-core-version.jar;

Currently, detection guidance in the form of regular expression signatures in the public space appear to be overly broad and bypasses have surfaced to circumvent them.

Updates to this post:

If you find these hashes in your software inventory then you have the vulnerable log4j in your systems: https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes
The presence of JAR files belonging to the log4j library can indicate an application is potentially susceptible to CVE-2021-44228. The specific files to search for should match the following following pattern: “log4j-core-*.jar”
Depending on the installation method, the location of the matching JAR file may also give indications as to which application is potentially vulnerable. For example, on Windows, if the file is located in C:\Program Files\ApplicationName\log4j-core-version.jar it indicates ApplicationName should be investigated. On Linux, the lsof utility can show which processes currently have the JAR file in use and can be run via the following syntax: “lsof /path/to/log4j-core-version.jar;”
Currently, detection guidance in the form of regular expression signatures in the public space appear to be overly broad and bypasses have surfaced to circumvent them.
This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team.
Added to Further Information: https://logging.apache.org/log4j/2.x/security.html
Details regarding exploitability of VMware products impacted by VMSA-2021-0028
Additional details on VMware mitigations (Full details)
Additional details on Jamf mitigations (Full details)
Remediation and mitigation guidance from Apache Foundation (Link)
Updated with clarification that version 1.x of Log4j is not susceptible to this vulnerability (Link)
Updated with clarification that remote code execution is possible for some non-default configurations of software running Log4j 1.x. (Link)
Updated to reflect Randori position that updating your version of Java is not sufficient to prevent exploitation of the vulnerability.
Updated to reflect that Log4j version 2.15.0 was originally released to remediate CVE-2021-44228. Shortly thereafter, it was discovered that the patch was not sufficient to protect against attacks in certain non-default configurations. Log4j version 2.16.0 was released to mitigate this latest development and a new designator, CVE-2021-45046, was assigned for the vulnerability. Initially the issue was rated a CVSS 3.7 as the impact was determined to be a denial of service only. On 12/17, the issue was upgraded to a CVSS 9.0 due to researchers demonstrating it could be leveraged for remote code execution.
Updated to reflect new versions of Log4j released to address Log4Shell vulnerability
Updated to include release of Log4j 2.17.0