On 9 and 10 December 2021, a series of Tweets and GitHub repositories were created that identified a zero-day vulnerability in Log4j 2, otherwise known as CVE-2021-44228 or “Log4Shell”. Naturally, our own crack team of cyber experts jumped to attention, and this is what we learned.
First and foremost, the vulnerability in question potentially allows remote code execution (RCE), so if an attacker were to successfully exploit it, they could execute commands on the server running the software. The result? Anything from data exfiltration to server access, depending on what software is running and what level of access it has.
As you can imagine, this is a pretty severe vulnerability. While we’re still awaiting an official CVSS score, some sources are saying this could be a solid 10. Log4j is a popular library used in many Java-based applications, making it the perfect storm of a high severity vulnerability in a wide spread piece of software. There are also several Tweets on Twitter indicating that attackers are already looking to leverage the vulnerability to target potential victims.
The infosec community has mostly focused on targeting web applications, which remains the highest immediate threat. However, it’s important to remember that this vulnerability is not restricted to web applications; any application that logs any user-controlled data could be open to exploitation. This includes desktop applications which, in this context, could lead to privilege escalation.
FUD Busting
Over the weekend, since the release of the exploit and proof of concept (POC), we have seen a lot of bold claims suggesting some very large organizations and vendor tools are vulnerable to this exploit.
I think it’s important to state upfront that “vulnerable” is not equal to “exploitable”. I don’t want to downplay the significance of this vulnerability, but for a modern version of Java (anything post 8u191), achieving remote code execution is very difficult unless the target application fulfils a specific set of requirements that are not enabled or present by default.
With that out of the way, let’s get technical.
Affected Versions
- Log4j2 <=2.15.0
This vulnerability affects versions 2.x of Log4j up to but excluding 2.15.0 (i.e., 2.14.1 and prior). Versions 1.x of Log4 are not affected.
Simply having a vulnerable version of Log4j is not enough for attackers to gain remote code execution. While this is true for older versions of Java (anything before 8u191), later versions of Java disable `trustURLCodebase` by default. While this means RCE is more difficult, it can still be achieved by using features in the hosted applications that could lead to deserialisation gadgets. Veracode have a detailed writeup on this that explains all the nuances for each impacted version.
Remediation
The official remediation for this vulnerability is to update all instances of Log4j 2 (versions <= 2.14.1) to version 2.15.0.
Temporary Remediation
Where it is not possible to update the version of Log4j 2 to 2.15.0, you can put into place a temporary mitigation, as per the official advice from Apache:
- For versions >= 2.10: Set the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true
- For versions < 2.10: Remove the class JndiLookup from the classpath zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Exploited in the wild
We are already seeing signs of exploitation in the wild. Attackers have been quick to replicate the existing POC code and leverage it in automated attacks at scale. So far, these attacks are not showing signs of sophisticated targeting; instead, they are scanning the internet looking for low-hanging fruit by injecting a vulnerable string in the User-Agent header field. This field is often logged, especially when combined with error reporting.
There are two main exploit attempt paths being used in the wild. Firstly, we are seeing non-targeted RCE attempts blindly attempting to install crypto miners. These are running from automated scripts and, due the constraints listed above, are unlikely to be successful against most targeted hosts.
A second set of exploits are attempting to exfiltrate secrets from environmental variables. We have seen attackers trying to gain access to AWS secrets and tokens that may be present on host. Due to the nature of the vulnerability, even if remote code execution is not viable, the DNS request exfiltration methodology works in significantly more setups.
Detection
For web applications, depending on the level of logging you have, you may be able to detect signs of exploitation by searching for key strings. There is a specific structure to the field that is injected ‘${jndi:ldap:’.
This alone is not going to provide full coverage, as it will only detect the proof-of-concept attacks and low-level attackers. Additional URI handlers and methods to obfuscate or bypass this basic detection are already appearing in analysis by researchers in the community.
Additional logging may be found in the Java or application-specific log files. Failure to construct a valid URI syntax can lead to a stacktrace at the application level, so it’s important not just to focus on access or security logging, but also look at the application logs for related errors.
To combat this, several tools have been developed to aid in the detection of exploit attempts. A great example can be found here, which will check for known obfuscation and bypass techniques.
Post-compromise
If you do find signs of compromise, it is important to put your Incident Response plan into place quickly. Engage with business stakeholders to determine the best course of action. If the affected device is mission critical, determine whether you can isolate it from the internet or turn it off to prevent any further damage being done by the attackers.
Collecting as much context and forensic evidence as possible is key to gaining situational awareness. Attackers will be swift in migrating from the first affected device to additional hosts and services. As reported by Crowdstrike, the average “BreakOut time” for any given attack is 1 hour and 58 minutes, so acting quickly and responsibly is imperative.
Conclusion
This vulnerability illustrates the importance of having an appropriate dependency management process and tooling in place. While it wouldn’t completely protect your systems, it will make it simpler to identify which software uses the affected versions of the vulnerable library, so remediation or mitigation will be a lot faster and more efficient.
In many cases, how the library logs user input will determine whether that software is actually vulnerable. And while it may make sense to spend time determining if this software is vulnerable or not and which versions you are using, your efforts would likely be better spent trying to put the appropriate mitigations or remediations in place. Given the severity of the vulnerability and the likelihood that it’s being actively targeted by attackers, speed is essential.
If you’d like to learn more about Log4Shell, register for our free webinar on 21 December.
