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?
Immediately update to the latest version (2.15.0 or later) available here.
If you are using a version higher than 2.10.0 then you can also apply following mitigation involving a config change to the vulnerable system:
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 Java™ SE Development Kit 8, Update 121 Release Notes) protects against RCE by defaulting “com.sun.jndi.rmi.object.trustURLCodebase” and “com.sun.jndi.cosnaming.object.trustURLCodebase” to “false”.
More details - Log4j – Apache Log4j Security Vulnerabilities
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
https://logging.apache.org/log4j/2.x/security.html
https://www.lunasec.io/docs/blog/log4j-zero-day/
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes
Article Link: CVE-2021-44228: log4j2 0-day Vulnerability