Log4j: Letting the JNDI out of the bottle

In the diagram above, an attacker wants to attempt to exploit a Java web application. This hypothetical Java web application uses Log4j2 to log HTTP requests. The version of Log4j2 that implements logging for this application is vulnerable to the JNDI lookup vulnerability, and it is running a JDK version that has trustURLCodebase set to true.

The attacker issues an HTTP request in which they modified their user-agent string to issue a JNDI lookup:

This user-agent gets logged by the Java web application. Log4j2 sees the JNDI lookup and honors it. The web application server looks up the domain seemsleg.it, and issues an LDAP query to:

The LDAP server listening on port 1389 on seemsleg.it is designed to respond to the query and tell the client that the resource they’re looking for is located elsewhere. In this case, it tells the client who made the request to download the java class file at:

Since trustURLCodebase is set to true, the web application server sends an http request to seemsleg.it:8888/notmalware, downloads the malicious java class file, and loads it. 

Other Avenues of Exploitation

Let’s assume your software vendor decided to patch this vulnerability by blocking certain strings from being logged, such as:

There are bypasses to get past brittle blocklists that rely on detecting these strings. For example:

These two strings would end up normalizing to:

The Sophos blog recently included a post with even more blocklist bypasses that have been observed in the wild. In addition to blocklist bypasses, it’s been suggested that there are other JNDI methods that could be used to exploit vulnerable servers. The LunaSec blog post mentioned earlier links to the Veracode blog post that shows dedicated attackers could try to leverage existing code on a server (sometimes referred to as a “gadget“) to gain code execution.

Possible Attack Surface

Y’know whenever you go to install the latest JRE update, and while you’re in the middle of installing it during the load screen the little banner that pops up saying “Billions of devices run Java”? Well, that’s not just marketing fluff. There are tons of devices out there running some form of the Java runtime environment. 

While every device out there running Java might not be utilizing the Log4j2 library, know that there are enough applications out there that are that this vulnerability will likely be a problem for months if not years to come as companies, organizations, and vendors scramble to figure out which Java applications of theirs use Log4j2 and are therefore potentially vulnerable–and the attack surface is pretty wide.

As an example of an unexpected attack surface, on Friday I saw security researcher John Hammond tweeting about getting remote code execution in the popular Java-based video game Minecraft. That inspired me to try it on my own. After a day of futzing around, I managed to exploit Minecraft, but with some caveats. If you’re curious, see my video about it below: 

The associated presentation–including clickable resource links–is also available for download here.

Here are some of the vendors who have confirmed they were using the vulnerable Log4j2 libraries and their recommendations going forward:

• Okta RADIUS AND MFA Server
• NetApp Products
• VMware vCenter and various other product lines
• Various Red Hat product lines 
• Splunk

As time goes on, it is highly likely that other IT and IT security vendors will post their own advisories related to this vulnerability. I came across this GitHub repository of vendors who have released advisories and guidance for their products in addition to the links above. Additionally, CISA, in collaboration with security researcher Kevin Beaumont, made a spreadsheet of affected products, and they provided links to security advisories from the vendors for those seeking further guidance.

The worst part about all of this is that there are likely software stacks, appliances, and applications that will never be upgraded. Either due to the software/appliance being considered end of life, the software project being considered too important and business critical to update, and/or cases in which either the company that wrote the software or the developers are no longer available to update the application. 

Mitigations and Remediation

As usual, the most obvious path for remediating this vulnerability is to update to the latest implementation of Log4j2. As of right now that’s version 2.16, in which they’ve disabled the lookup functionality in its entirety. 

Of course, because this is a library that is likely to be a part of a much larger Java application or applications in your environment–some of which you may have the ability to modify and many, many others that you will likely have to wait for vendor patches to actually do anything–patching it by updating the vulnerable library is going to be much more easily said than done.

If you’re using Log4j2 between versions 2.10 and 2.14.1, set this option on the command line when running your Java application:

Alternatively, you can also set the environment variable:

to achieve the same effect.

Recall that in order to have the vulnerable application download and run the malicious Java class file, they need to be running a vulnerable version of the JDK with the trustURLcodebase parameter set to true. 

If you are able to update the JDK version being used to run your Java applications, then that would serve as a somewhat effective mitigation against the LDAPRefServer exploitation method. Recall that other exploitation methods (exfiltration of environment variables and use of existing gadgets) still exist, and they could still be used to target vulnerable Java applications.

Now, what if you don’t have the ability to update the library, change the command line arguments, or change the version of the JDK your Java application uses? 

Well, if you’re feeling particularly brave–and you’re absolutely sure that your organization doesn’t use any of the JNDI lookup functions in the log4j2 library–you can use the zip command to delete them out of the log4j2 library’s JAR files:

Considering the fact that you’re ripping out entire java class files from the library, I would highly recommend testing this mitigation before messing with any production applications.

What if you don’t have the option to use any of these mitigation methods? 

Consider the fact that this exploit requires the system being attacked to make DNS, LDAP, and/or HTTP connections outbound. Here are some questions related to defense in depth and security monitoring to consider: 

• Does the server have a firewall deployed? Is there an egress filtering policy applied? 
• Is there a firewall at the perimeter of your network or your cloud deployment? Is egress filtering being applied there? 
• Is there an HTTP proxy that your systems are required to use for HTTP connectivity? 
• Do you have DNS query logs available? Do your logs identify source IP addresses that are making the DNS requests? If so, consider searching for DNS queries where the source IP addresses are your java application servers and/or appliances, and sorting them by least frequent occurrence.

These are all effective network boundary defenses that can stop the exploit from succeeding, as well as invaluable data sources for threat hunting in order to search for anomalies and/or possible exploitation attempts.

In cases where network boundaries cannot be deployed or there is insufficient logging, consider endpoint protection solutions to detect post-exploitation activity, such as: 

• EDR/XDR solutions
• sysmon
• osquery
• auditd

If the Java process for your application is suddenly making outbound connections it doesn’t typically make, starts running child processes it doesn’t typically spawn, or drops new files to disk that have never been seen in the network before, know that these are anomalies worth investigating. Hopefully your EDR/XDR tools will make that task easier.

Conclusion

I’ve heard security researchers stating that this “Log4Shell” vulnerability has a “long tail.” What that means is that since Log4j2 is so ubiquitous–and because it is the de facto standard for logging anything in java applications–it’s highly likely that we’ll be seeing a lot of potential attack surface with this vulnerability, some of it obvious, some of it not so obvious. 

It’s also likely that due to the nature of this vulnerability and how java applications are the backbone of organizations and entire business verticals all over the world, patching this vulnerability will be no easy matter.

The best advice I can offer is to do the best you can with what you have. Take it one step at a time. I’ve often been told that cybersecurity isn’t a sprint, but a marathon. Make sure you take care of yourself, your colleagues, and your peers. Remember to step away from the keyboard once in a while, and–especially with the holiday season coming up–take time for yourself, your family, and your friends.

Happy holidays, and happy hunting.