Log4j2 is an open-source logging framework embedded in many Java-based applications on both servers and end-user systems. In late November 2021, Alibaba's Chen Zhaojun identified a remote code execution vulnerability, which was eventually reported with CVE ID: CVE-2021-44228, which was made public on December 10, 2021. The exploit of the vulnerability is done through improper deserialization of user input that is passed to the framework. It allows remote code execution and can allow an attacker to leak sensitive data, such as environment variables, or run malicious software on the target system.
The identified vulnerability affects all versions of Log4j2, from version 2.0-beta9 to version 2.14.1. The first methods of patching this issue resulted in several release candidates, culminating in the recommendation to upgrade the framework to Log4j2 2.15.0-rc2 at the time of this blog.
Given the trivial complexity and the nature of the widespread exploitation observed, mitigation should be considered critical in any environment with identified software that takes advantage of vulnerable versions of Log4j2.
Detect exploitation of Log4Shell in Elastic Security
Elastic Security users can use the event correlation detection rule to identify the active exploitation of the log4j2 vulnerability. Depending on the format of your host-based event data, you may need to modify this detection to match your data fields.
Detection rule if you use endpoint data
sequence by host.id with maxspan=1m
[network where event.action == "connection_attempted" and
process.name : "java" and
/*
outbound connection attempt to
LDAP, RMI or DNS standard ports
by JAVA process
*/
destination.port in (1389, 389, 1099, 53, 5353)] by process.pid
[process where event.type == "start" and
/* Suspicious JAVA child process */
process.parent.name : "java" and
process.name : ("sh",
"bash",
"dash",
"ksh",
"tcsh",
"zsh",
"curl",
"perl*",
"python*",
"ruby*",
"php*",
"wget")] by process.parent.pidDetection rule if you use Auditbeat data
sequence by agent.id with maxspan=1m
[network where event.action == "connected-to" and
process.name : "java" and
/*
outbound connection attempt to
LDAP, RMI or DNS standard ports
by JAVA process
*/
destination.port in (1389, 389, 1099, 53, 5353)] by process.pid
[process where event.type == "start" and
/* Suspicious JAVA child process */
process.parent.name : "java" and
process.name : ("sh",
"bash",
"dash",
"ksh",
"tcsh",
"zsh",
"curl",
"perl*",
"python*",
"ruby*",
"php*",
"wget")] by process.parent.pidDetection rule if you use streamed events from Endgame
sequence by agent.id with maxspan=1m
[network where event.category == "network" and
process.name : "java" and
/*
outbound connection attempt to
LDAP, RMI or DNS standard ports
by JAVA process
*/
destination.port in (1389, 389, 1099, 53, 5353)] by process.pid
[process where event.type == "start" and
/* Suspicious JAVA child process */
process.parent.name : "java" and
process.name : ("sh",
"bash",
"dash",
"ksh",
"tcsh",
"zsh",
"curl",
"perl*",
"python*",
"ruby*",
"php*",
"wget")] by process.parent.pidThis detection rule looks for a sequence of an outbound connection attempt to standard ports for LDAP, RMI, and DNS (which are often the target of recently observed JAVA/JNDI injection attacks ) followed by a child process from the same instance of Java process.
Now, let's see how this rule detects exploitation of the log42j vulnerability:
The screenshot above shows an attacker exploiting the vulnerability with a Base 64 encoded payload, targeting a vulnerable sample application that Christophe Tafani-Dereeper created.
This screenshot shows the detection of active CVE-2021-44228 exploit within Elastic Security, detailing both the alert view and the exploit timeline.
The above screenshot shows that in investigating the Java detection alert you ran a shell script to download and run a bash script.
Community detections
Several community members who discussed the widespread exploitation of the vulnerability provided information on various early detection methods that analysts can leverage to identify whether the systems they are using have been exploited or are actively exploited:
-
The GreyNoise team shared a number of uploads, including those with encoded and decoded variants for analysts looking to explore the logs stored on their systems. This was supplemented by a list of initial tagged IPs that attempted to exploit the vulnerability.
-
Nextron Systems' Florian Roth provided a number of checks for local exploitation using grep/zgrep, along with some initial YARA signatures in a Gist included on his Github account. Florian also shared a method to generate Thinkst CanaryTokens in order to test systems that you can manage in relation to exploitability.
-
Rob Fuller (Mubix) shared a list of known file hashes on vulnerable versions of the framework, here.
Additional mitigation strategies
Outside of the Apache team's recommended guidance on deploying the latest patched versions of the Log4j2 framework for upgrading, several mitigations were suggested to prevent exploitation:
-
Fastly suggested checking if your version of Log4j supports running JVM with JAVA_OPTS = -Dlog4j2.formatMsgNoLookups = true to disable search functionality on remote server. This should apply to versions 2.10.0 to 2.15.0.
-
To avoid lateral movement from a vulnerable host, or exploitation across the network, it is recommended to limit the connectivity of potentially vulnerable systems to external resources only to trusted applications or services.
