Stranger Danger: Live hack of how a Log4Shell exploit works

The Log4Shell vulnerability took the Java community by surprise at the end of 2021, and many organizations are still mitigating its impact. To help development teams stay informed as the situation unfolds, Snyk has created and continues to update its Log4j vulnerability resource center.

During a recent Stranger Danger live hack, Simon Maple, Field CTO at Snyk, Eric Smalling, Senior Developer Advocate at Snyk, and Micah Silverman, Director of DevSecOps Acceleration discussed the Log4Shell vulnerability and demonstrated how an exploit could work.

Log4Shell TL;DR

Log4Shell is a highly prevalent, critical, and easily exploited vulnerability within the Log4j2 Java logging framework. This vulnerability has impacted a large number of Java applications as Log4j2 is so often used across so many other open source libraries.

“As evidenced by the fact that this vulnerability has been sitting here dormant since 2013, sometimes we have unexpected side effects,” said Micah. “This is kind of the nature of open source projects.”

To remediate this vulnerability, developers must identify where their applications are using the Log4j2 library — as either direct or indirect dependencies — and upgrade to version 2.17.1. This not only mitigates the Log4Shell vulnerability, but also an additional denial of service vulnerability that was disclosed shortly after.

Want to learn more? We put together a full remediation guide for Log4Shell.

Anatomy of Log4Shell

In 2013, the ability to use Java Naming Directory Interface (JNDI) references via interpolated strings in log messages was added to the Log4j library. Interpolated strings might contain variables, function calls, or other resolvable expressions. The problem is that the JNDI might look up URLs in these resolvable strings, triggering a network call to a malicious endpoint.

Furthermore, an unauthorized LDAP server could respond to the JNDI request with a malicious reference to a remote Java class or other unwanted code. This class could then be deserialized, even if it’s not on the application’s class path, resulting in a remote code execution (RCE) attack.

Log4Shell exploit demo

For our live hack demonstration, we’ll use a Log4Shell exploit example (available on Github) we’ve built using Java that we’ll run on a Tomcat server. When we input an incorrect password on the login page, our application notifies us that our information will be logged.

“Logging across Java frameworks and your application when errors or exceptions happen, or sometimes when it’s just a regular transaction, is common,” explained Simon. “This helps you understand the different flows and how individuals are using your site.”

Jumping over to our application code, we can see that when a username is incorrect, we use Log4j to log the username. Situations like this, where users can input data that is subsequently logged, is the most common way for the Log4Shell vulnerability to be exploited.

For example, we can use the login textbox to inject a malicious string that sets us up for an RCE attack. But first, let’s walk through our Python exploit script. The most important thing to understand about this script is that it generates a Java class that will create a new socket when it’s initialized, which will then connect to our own server.

“This is effectively going to be part of a remote proxy that we’ll set up,” explained Simon. “The class will run on a continuous loop, taking commands, running commands, and sending commands back to our connected service.”

We’ll create and compile the Java file on our malicious server and make it available via an HTTP service. Then we will create our LDAP server that sends back a string for the target application’s JNDI to look up our malicious Java class.

Once we stand up the LDAP server and HTTP server, we’re almost ready to run the exploit. To execute the “shell” part of Log4Shell, we’ll also set up a reverse proxy server using netcat, which is a networking utility. The reverse proxy ultimately enables us to execute remote commands on the Tomcat server, meaning the application and server become vulnerable to further attacks.

We execute the exploit by inputting our malicious string into the login box on the target application’s login page. Once this string gets logged by Log4j, the library will also attempt to resolve the interpolated string. This causes the application to use the JNDI service to reach out to the LDAP server, pull down the reference to our malicious Java class on the HTTP server, and execute it locally. This Java class then reaches out to netcat, creating our reverse proxy.

Mitigating Log4Shell with Snyk

As we’ve mentioned before, the ideal way to mitigate Log4Shell is to identify and upgrade all Log4j instances within your indirect and direct dependencies. Snyk Open Source can automatically scan your dependencies for packages that contain vulnerabilities like Log4Shell.

The Snyk platform starts by identifying and categorizing all of the artifacts within your project to determine how they can be scanned. For example, Snyk will perform software composition analysis (SCA) scans on pom.xml files and static application security testing (SAST) scans on Java files. Snyk can also scan infrastructure as code (IaC) configurations and Docker files for containerized applications.

After we scan our vulnerable application from above, we can open the scan results for our pom.xml file, which is the Maven configuration file that contains our dependencies. We can also see our dependency tree within the Snyk interface showing that our application uses Log4j as both a direct and indirect dependency. By clicking on the Fix this vulnerability option, Snyk can automatically open a pull request (PR) to upgrade all Log4j instances to version 2.17.1. If we rerun the previous exploit, we’ll see that it no longer works.

Similarly, developers can use the Snyk plugin for IntelliJ (or another IDE) or the Snyk CLI to scan for security issues and fix them directly during development. Snyk integrates throughout the entire development process to streamline application vulnerability management.

In some situations, organizations won’t be able to immediately upgrade the vulnerable packages, so they’ll need to consider other options to mitigate the risks of Log4Shell. Developers could remove the JNDI lookup class or implement other quick-fixes, but these aren’t as effective as the official patch in newer versions of the library.

No matter how developers choose to mitigate the Log4Shell vulnerability, Snyk can help identify instances of Log4j and thousands of other potential vulnerabilities by scanning a project’s open source dependencies or containers. This ensures organizations have the visibility they need to understand the risk profile of their applications.