Simulating and Preventing CVE-2021-44228 Apache Log4j RCE Exploits

Picus Labs has updated the Picus Threat Library with attacks that exploit CVE-2021-44228 Remote Code Execution (RCE) vulnerability affecting Apache Log4j - the ubiquitous Java logging library.

What is the CVE-2021-44228 Log4j Unauthenticated RCE Vulnerability?

Apache Log4j versions prior to 2.15.0 do not protect against attacker-controlled LDAP and other JNDI-related endpoints. When message lookup substitution is enabled, an attacker with control over log messages or log message parameters can execute arbitrary code loaded from LDAP servers. This vulnerability is also dubbed Log4Shell or LogJam.

Test your security controls now: Prevent Log4Shell Exploits with Picus

The CVE-2021-44228 is a remote code execution vulnerability that can be exploited without authentication. Therefore, CVE-2021-44228 is an unauthenticated RCE vulnerability affecting Apache Log4j versions before 2.15.0.

Log4j Vulnerability Updates (CVE-2021-44832, CVE-2021-45105, CVE-2021-45046)

Update (December 28, 2021): A new vulnerability (CVE-2021-44832) is found in Apache Log4j2 versions 2.0-beta7 through 2.17.0. CVE-2021-44832 is an Arbitrary Code Execution vulnerability. Since it can be exploited by an attacker with permission to modify the logging configuration, its severity is lower than Log4Shell (CVE-2021-44228). Its base CVSS score is 6.6 (medium). This vulnerability is fixed in Log4j versions 2.17.1 (Java 8), 2.12.4 (Java 7) and 2.3.2 (Java 6).

Update (December 16, 2021): Since we published this blog post, 2 new vulnerabilities have been discovered.

Apache Log4j versions prior to 2.16.0 are vulnerable to information leaks and remote/local code execution (CVE-2021-45046) flaw. It was first discovered as a denial of service vulnerability. However, later found out that it is also a remote/local code execution vulnerability, which increases its CVSS score from 3.7 (low) to 9.0 (critical).

CVE-2021-45105 is another vulnerability found in Apache Log4j versions prior to 2.17.0. It is a denial of service vulnerability with a CVSS score of 7.5 (high). Similar to CVE-2021-45046, malicious recursive lookup sent via Thread Context Map (MDC) input causes StackOverflowError in this vulnerability.

To See the Full Infographic, Click Here

What is the Impact of the Log4j RCE Vulnerability? 

CVE-2021-44228 vulnerability enables remote code executions on systems running vulnerable Log4j versions and allows the attacker full control of the affected server.  For example, attackers can exploit CVE-2021-44228 to run malicious codes and install webshells as backdoors on vulnerable systems for maintaining access and post-exploitation.

CVE-2021-44228 is a vulnerability that affects the default configurations of several Apache frameworks, including Apache Struts2, Apache Solr, Apache Druid, and Apache Flink. Thus, it is a high-impact vulnerability affecting widely used software.

Update: CVE-2021-45046 vulnerability also enables remote code execution. However, the delivery of the payload is different from CVE-2021-44228 vulnerability. Exploiting this vulnerability requires control over Thread Context Map input data where the attacker needs to create a malicious payload using JNDI Lookup Pattern. When exploited, this vulnerability results in information leak and remote code execution in some environments and local code execution in all environments.

CVE-2021-45105 vulnerability enables denial of service (DoS) for Log4j versions prior to 2.17.0. Similar to CVE-2021-45046, attacker-controlled Thread Context Map input data can be leveraged to create uncontrolled recursion from self-referential lookups.

What is the Current Situation?

According to BadPackets and Cert NZ,  attackers are actively scanning the Internet for systems running vulnerable Log4j versions and exploiting CVE-2021-44228. This is an expected adversary behavior for a remotely exploitable and unauthenticated code execution vulnerability. 

Log4j Exploit

In order to exploit the Log4j vulnerability, the attacker must initiate the generation of a log entry containing a JNDI request. Thus, the Log4j exploit payload must be contained within logged errors such as exception traces, authentication failures, and other unexpected vectors of user-controlled input. Then, Log4j must process the exploit payload. 

The exploit payload can be sent in a header field of an HTTP request. Picus Labs researchers validated the following sample payload included in the user-agent header:

Note that you need to run a malicious LDAP server to exploit the CVE-2021-44228 vulnerability and modify the example.com part of the payload.

Update: According to the Microsoft Threat Intelligence Center, nation-state actors from various countries are already utilizing Log4j vulnerabilities for their benefit. However, it is not easy to determine where these attacks originate from because attackers are using TOR (The Onion Router) to stay anonymous.

From their TTPs (Tactics, Techniques and Procedures), it can be deduced that APTs like PHOSPORUS and HAFNIUM are mutating their ransomware using Log4j vulnerabilities. In the future, it is expected these vulnerabilities will be part of many ransomware attack campaigns.

What Should You Do for Remediation?

The CVE-2021-44228 Log4j RCE vulnerability was patched in Log4J v2.15.0  by Apache. Therefore, it is not a zero-day vulnerability. To protect against these attacks, we highly advise organizations to identify vulnerable systems on their networks and update vulnerable Log4j installations.

This vulnerability can also be mitigated in previous releases (>=2.10):

• by setting the system property "log4j2.formatMsgNoLookups" to "true" 
• by removing the JndiLookup class from the classpath (example command: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). 

Java 8u121 protects against RCE by setting the properties "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false."

Please keep in mind that Log4J v1 is no longer supported and will not receive patches to address this issue. Log4J v1 is also vulnerable to other RCE attacks, and we strongly advise you to upgrade to Log4J 2.15.0 as soon as possible.

Update: Due to new vulnerabilities found, Apache released Log4j version 2.17.0. This latest version remedies recently found CVE-2021-45046 and CVE-2021-45105 vulnerabilities.

How Can You Detect CVE-2021-44228 Vulnerability Exploitation Attempts?

Florian Roth, the Head of Research at Nextron Systems, has shared a set of YARA rules for detecting CVE-2021-44228 exploit attempts.

You can also utilize the following shell commands to search for exploitation attempts in uncompressed and compressed files respectively in the /var/log directory and all its subdirectories:

How Picus Helps Simulate and Prevent CVE-2021-44228 Exploits?

We strongly suggest simulating CVE-2021-44228 vulnerability to test the effectiveness of your security controls against Log4J attacks, determine gaps, and utilize prevention signatures to fill your security gaps using the Picus Security Control Validation Platform. 

Just click Start to see and try how you can simulate Log4j attacks and obtain prevention signatures using Picus with just a few clicks.

Picus Threat Library includes the following threat for CVE-2021-44228 vulnerability. Moreover, it contains 1500+ vulnerability exploitation and endpoint attacks in addition to 11.000+ other threats as of today.

Picus also provides actionable mitigation content. Picus Mitigation Library includes prevention signatures to address CVE-2021-44228 Log4J RCE and other vulnerability exploitation attacks in preventive security controls. Currently validates signatures are given below:

We will update the above list when Picus Labs validate the signatures of other vendors/products.

Which Log4j  Versions are Vulnerable?

CVE-2021-44228 vulnerability affects Apache Log4j versions 2.0 to 2.14.1. SHA-256 hashes and default filenames of all vulnerable Log4j versions are given in the below table:

Indicators of Compromise (IOCs)

It has been observed that the attached IP addresses are exploiting CVE-2021-44228 Log4j vulnerability. Although most of them are IP addresses of TOR exit nodes and blocking them may result in false positives, it is suggested to block these addresses in such critical cases.