The Latest Information on the Log4J Vulnerability
SIEM
Posted: December 15
As the situation develops the latest information can be found here.
What is CVE-2021-44228?
CVE-2021-44228 is a vulnerability in the popular Java logging library Apache Log4j.
The vulnerability affects Apache Log4j 2 versions 2.0 to 2.14.1. It is a critical vulnerability with a CVSSv3 rating of 10.0, allowing any unauthenticated attacker to remotely execute arbitrary code.
It was disclosed by Chen Zhaojun, Alibaba Cloud Security Team, and released on the 9th December via Twitter with a proof-of-concept code available on GitHub.
Why is it critical?
Log4j is a logging library maintained by Apache that is widely used and commonly embedded in a large variety of Java software, including open-source software, cloud services, and commercial applications like mobile and smart devices.
Many cloud services, for example Steam and Apple iCloud, were initially impacted, although many providers have acted swiftly and have already mitigated the vulnerability.
There are some indications that the earliest attacks occurred as far back as the 1st of December and rose from there, but didn’t hit critical mass until the proof of concept exploit code was released on the 9th of December. The vulnerability was then seen being exploited in the wild in remote-code attacks against Minecraft servers. Reports came in quickly and have been mounting since that other threat actors are already exploiting the vulnerability in the wild, with widespread mass-scanning to fingerprint and identify vulnerable systems also being seen, alongside malware distribution. While no major data breach resulting from the vulnerability being exploited has so far been announced, attack activity continues to rise.
What makes the vulnerability really insidious is that it can be embedded in a diverse variety of different devices, applications, and services, including in the supply chain. This is not always obvious or documented, so there’s a hidden risk. In addition to remediating the vulnerability, organizations must also prioritize detection and response to safeguard against the resulting blind risk.
How does an attack work?
The Java Naming and Directory Interface (JNDI) can query data stored in a directory service like LDAP from a Java application.
Log4j v2 offers a capability called Property Substitution to specify tokens that reference properties that are defined elsewhere in an application.
The vulnerability is due to the way that log messages are processed by the log4j processor. If an attacker sends a specially crafted message, it is possible to load external code via JNDI and execute it.
To exploit the vulnerability an attacker must send data that will be logged, for example an HTTP header like the HTTP User-Agent string:
- The User-Agent string is passed to Log4j for logging.
- Log4j property substitution unpacks and executes the JNDI request to connect to a malicious LDAP server.
- An LDAP server under control of the attacker services a malicious Java class back to the vulnerable server.
- The vulnerable server deserializes and executes the malicious class, executing arbitrary commands defined by the attacker.
What happened in the missing 8 days?
According to reports by CloudFlare and Cisco Talos, the vulnerability was first seen being exploited in the wild on the 1st of December and the 2nd December. The vulnerability was not disclosed until the 9th of December.
This poses some uncomfortable questions, like when did the first attacks actually occur, and what happened in those intervening 8 days? It also begs the question how the original researcher found the vulnerability?
From a practical point of view, this is something that you should be investigating. There is a good chance that threat actors have been exploiting this for longer than assumed, and that some organizations were compromised long before the flaw became publicly known.
What Now?
Mitigations being circumvented
CISA and others have provided a wealth of information on how to mitigate and remediate the vulnerability, and we are not going to replicate these in detail here.
One thing to note is that it is being reported that some recommended mitigations have already been circumvented or shown to be ineffective. WAF workarounds based on blocking the LDAP string are already being bypassed. Upgrading JVM is also no longer an effective mitigation strategy.
Be cautious which advice you follow and stick to official channels. CISA has published a comprehensive list of impacted products and services.
Our own Threat Labs team has seen an uptick in attacks that actively evade security controls by obfuscating the query. We’ve also seen more attacks leveraging different HTTP Headers than just the “User-Agent” header seen in the original PoC. Like the mythical hydra, exploitation in the wild is growing many heads, making it increasingly difficult to rely on static indicators of compromise like IP addresses and domain names to detect initial exploitation.
Defenders must instead expand the scope of monitoring and also hunt for post-exploitation activity such as privilege escalation and lateral transfer.
Additional Guidance for Securonix Users
Stay vigilant. Even if you have patched the vulnerabilities, we do not know how long it was actually being exploited in the wild. We must also remain wary of related weaknesses that may still be disclosed. Adopt a “Detect and Respond” mindset and assume you’ve already been breached.
If you are a Securonix customer, we have released our own guidance on what you can do to ensure you are protected. Make sure you enable the newly available policies, and ask about our Autonomous Threat Sweep – we were scanning our customers and helping them assess their exposure as soon as information became available on the 10th of December.
