CIRCL » TR-65 - Vulnerabilities and Exploitation of Log4j (Remote code injection in Log4j)

Overview

CVE-2021-44228 vulnerability enables remote code injection on systems running Log4j. The attacker has to trigger a log entry generation containing a JNDI request. The vulnerability can be exploited without authentication. The exploit needs to be processed by Log4j. Impacted Log4j versions are: 2.0 to 2.15.0. The fix was partial for version 2.15.0 as additional vulnerabilities such as CVE-2021-45046 were published in 2.16.0. Later version 2.17.0 was published fixing an additional vulnerability CVE-2021-45105. Then version 2.17.1 was published fixing an additional vulnerability CVE-2021-44832.

Recommendations

We recommend to update to log4j 2.17.1 including fixes for CVE-2021-44832, CVE-2021-45105 and previous fixes (2.16.0) which disables JNDI by default Commit patch - and release info;
Set to the JVM args log4j2.formatMsgNoLookups set to True in case not patched. Configuration documentation;
On recent JDK, com.sun.jndi.rmi.object.trustURLCodebase must be set false to disallow access to remote resources;
Sanitize log data before processing into Log4j (in complement to patching Log4j to the latest version as escaping is an endless stream of creativity);
For recent version of Log4j (December 2021) check the lists of allowedJndiProtocols, allowedLdapHosts and allowedLdapClasses must be none;
If you cannot update log4j, This issue can be mitigated in prior releases (<2.17.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

General recommendation

As we have an endless stream of vulnerabilities in Log4j and especially advanced logging libraries, we recommend to re-evaluate the option to use a simplified logging library or reimplement a very simple logging mechanism.

Detection and Incident Response

Review logs generated for Log4j processing and focus on JNDI entries;
Review outbound connections of system running Log4j;
Use YARA rule in log4j RCE Exploitation Detection gist;

Use the following or similar shell commands:

egrep -i -r '\$\{jndi:(ldap[s]?|rmi)://[^\n]+' /var/log

find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i '\$\{jndi:(ldap[s]?|rmi)://[^\n]+'

But obfuscation can be performed by attackers in numerous ways to obfuscate the JNDI string. The tool log4shell-detector improves the detection and can be used to detect potentially obfuscated ways. We recommend to use different methods for detection and not only the above regular expressions.

Known vulnerable software

A list of security advisories and bulletins from various vendors is maintained by SwitHak at the following location. NCSC-NL maintains another list of vulnerable software and especially the status.

The patch with the vulnerability was introduced the 18th July 2013 at 19:48.

Cloudflare confirmed that the vulnerability was already abused the 2021-12-01 04:36:50 (UTC).

Similar vulnerability were disclosed in a Black Hat talk in 2016 and similar potential vulnerabilities (such as CVE-2009-1094) were documented for LDAP in 2009.

Tools

NMAP nse script to inject JNDI payloads - Injects a Huntress/CanaryTokens/custom log4shell payload in HTTP requests described by JSON templates. Results expire after 30 minutes.

References

Classification of this document

TLP:WHITE information may be distributed without restriction, subject to copyright controls.

Revision

Version 1.5 - TLP:WHITE - First version - 10th December 2021 - Updated - 29th December 2021

TR-65 - Vulnerabilities and Exploitation of Log4j (Remote code injection in Log4j)