Background
The Apache Software Foundation has released a security advisory with patch and mitigation details to address a remote code execution vulnerability (CVE-2021-44228) affecting Log4j versions 2.0-beta9 to 2.14.1. Over the past 24 hours, Zscaler ThreatlabZ has noticed several in-the-wild exploit attempts of this issue and expect this trend to rise over the weekend. A remote attacker could exploit this vulnerability to take control of an affected system which makes it extremely important for organizations to patch immediately as well as perform security scans for indicators of compromise from this exploit.
What is the issue?
An attacker can download and execute a malicious payload by submitting a specially crafted request to the vulnerable system. The attacker can then control log messages or log message parameters to execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. Log4j is incorporated into many popular frameworks, making the impact widespread.
Versions Impacted
The vulnerability impacts multiple versions of Log4j and the applications that depend on it.
Log4j versions 2.0 to 2.14.1 are vulnerable to this CVE.
What can you do to protect yourself?
Implement one of the mitigation techniques below.
- Java 8 (or later) users should upgrade to release 2.17.1 available here.
- Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).
- Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Older (discredited) mitigation measures
The following mitigation measures were proposed initially. But, these were later found to be insufficient.
- Set system property "log4j2.formatMsgNoLookups" to “true” or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against RCE by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
More details - https://logging.apache.org/log4j/2.x/security.html
How to identify if you are impacted by this:
- Run the following command to check log4j version running on the system
find / -name log4j.jar
Identify all instances of this jar being used and compare against the vulnerable versions of log4j.
Vulnerable log4j version hashes can be found here.
- grep for pattern ’\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+’ in the application logs to check for exploit artifacts.
Following the above, If you find the message “Error looking up JNDI resource” then that means you’re definitely vulnerable and there has been a failed exploit attempt. Successful attempts might not result in a message being logged, but a remote code can be downloaded and executed entirely in memory. Monitor for processes being spawned from the Java process, specifically shells which indicate compromise.
- Review logs of systems running the vulnerable version for unusual activity.
Zscaler Coverage
Zscaler ThreatLabz has added coverage to block exploitation attempts of this vulnerability through our Advanced Threat Protection and Advanced Cloud Sandbox Protection.
- Advanced Cloud Sandbox Signature. - Apache.Exploit.CVE-2021-44228
- Advanced Threat Protection Signature - Apache.Exploit.CVE-2021-44228
Details related to these signatures can be found in the Zscaler Threat Library.
References
