CVE-2021-44228: Log4J2 Remote Code Execution

yaara@cyberint.com

Dec 12, 2021

Watch on-demand webinar: Log4Shell Explained

Introduction

On Dec. 9, 2021, a remote code execution (RCE) vulnerability [1] in Apache log4j2 was identified, (dubbed “Log4Shell” by researchers), affecting massive amounts of servers all over the world.

As this vulnerability gains high traction worldwide, it’s important to note, that not only internet facing java applications are vulnerable, as user input can traverse to another non-internet facing machines and exploit these as well.

Over 70 proof-of-concept (POC) were published over the last weekend [2]. A patch has been released, and Log4j v2 should be updated to version 2.15.0.

Due to the nature of this vulnerability, and the fact that Log4j is widely used, Cyberint researchers believe that this vulnerability will be widely exploited in the near future.

Impact

Apache log4j 2 is an open-source Java-based logging utility, maintained by the Apache Foundation, and used broadly around the world.

The log4j library allows developers to log all kinds of data within their application, whether a user input, application errors or any other behavior of the application they wish to log. The developer will also be able to log different expressions, using special characters, most importantly in our case “{” and “$“.

These special characters can be used, for example, for getting system information. When inspecting the log "${java:version}", java will parse the "java:version part, address it as what is called a “lookup” (using the Java Naming and Directory Interface (JNDI) JNDILookup plugin), and output from java’s configuration the java version running on the server.

Some of the use-cases that the developer will want to achieve while logging actions within its application, is to access directory objects. This can be used by the Lightweight Directory Access Protocol (LDAP). This protocol is the core behind CVE-2021-44228.

Commonly, a developer will use LDAP to access local directory objects, however, remote directories can be addressed too.

For instance, logging the text "${ldap://localhost:1234/o=myObject}" will locate the "myObject" class object from LDAP on the local server and use it to read different configurations.

When using both JNDI and LDAP, the developer can call remote objects, on other machines than the local one, such as: "${jndi:ldap:///myRemoteObject}" that will fetch "myRemoteObject" class from , which can be controlled by a threat actor to load "myRemoteObject", and in turn, run malicious code on the remote server.

This remote command can be supplied in one of many ways. For example, a User-Agent field in an HTTP request, that will be logged by the developer, will cause a threat actor to run code on the remote server on his behalf.

Another example could be that the threat actor will cause an error in the application (I.e., providing wrong input), that will be logged by the app, and again, execute malicious code.
Several applications and services that can be vulnerable are:

Apache Tomcat
Apache Struts2
Apache Flink
Apache Spark
Apache Druid
Apache Solr
Apache Dubbo
Flume
Logstash
Kafka

With over a million suspected-to-be-vulnerable domains found by Cyberint Research Team, both internally and externally, the top 5 countries hosting vulnerable domains are United States, Japan, Brazil, Germany, and France:

Apache Log4j - number of vulnerable domains per country — Apache Log4j – number of vulnerable domains per country

Recommendations

Organizations utilizing vulnerable versions of Apache Log4j v2 < v2.15 are urgently advised to update to the fixed versions as detailed in the Apache Log4j security advisory [4] as soon as possible.
Another mitigation technique that will prevent a threat actor from utilizing this exploitation is modifying the following flag to disable lookup, by setting the system property:
log4j2.formatMsgNoLookups=true
Modifying environment variables is also available by:
LOG4J_FORMAT_MSG_NO_LOOKUPS=true
Mitigation is also available for releases 2.0-beta9 to 2.10.0, by removing the JndiLookup class from the classpath:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Other than verifying IPS/IDS products used by the organization security protects this vulnerability, it is important to look for WAF bypass techniques such as mentioned in tangxiaofeng7 POC [3] and verify these techniques do not affect the IPS/IDS vendor identification for this vulnerability.
Several tools have been released in order to identify if the given product might be at risk [4] or if exploitation is being used for this vulnerability [5]
Evidence was found that suggests the exploit is already being initiated by over 400 IPs (Appendix in IOC section below). Typically, a large portion of these IPs are related to the Tor browser, and it is highly recommended to block any communication from Tor nodes.
Yara rule that can detect utilizing this CVE exploitation has already been released [6] and might also mitigate exploitation