On December 9, a zero-day exploit was observed in the wild targeting a critical remote code execution (RCE) vulnerability in Log4j, the ubiquitous open-source logging tool. The list of affected platforms by what we now call the Log4Shell bug includes big corporate names such as Apple, Cloudflare, and Twitter. Log4j has also been embedded in popular Java ecosystem products, such as Logstash, Apache Kafka, Elasticsearch, and even Minecraft.
In short, a range of versions of the Log4j library has a vulnerability in them (CVE-2021-44228), that lets attackers exfiltrate data and execute malicious software by causing Log4j to write a specially-crafted log entry. And because logging has built-in flexibility by design, this vulnerability has a nearly infinite number of potential paths to exploitation.
Normally, widely-publicized vulnerabilities have one or two dangerous characteristics. In contrast, CVE-2021-44228 has five: Ease of exploitation; the potential for impact; the ubiquity of the targeted software; difficulty in finding and patching the target software; and flexibility of exploitation. All of these combine to create an opportunity that’s very attractive for malicious attackers. Organizations must understand the nature of Log4j to understand the scope of the risk it presents to them.
Understanding Log4j
Log4j stands for "Logging for Java." It's an extremely common open-source software library used by all kinds of Java applications to handle application logs. Importantly, Log4j is not a logging product, appliance, or console in the way people in IT or security would typically think about it. As an open-source library, Log4j saves the developer time writing a particular function by creating something they can use. It's free and saves a Java developer time writing logging functions themselves, so it's easy to get an idea of Log4j’s popularity and why it's everywhere Java applications run.
The important distinction (and a common confusion in the market right now) is that Log4j does not function like a SIEM or logging system such as Splunk or ArcSight. It's a library that lets Java applications log events and coding errors. It’s important because Java applications with Log4j are multiple orders of magnitude more common than SIEMs and logging systems, and that’s what makes the situation so potentially dangerous.
Help or hoax?
In the days following the discovery of the Log4j vulnerability, Cybereason, a prevention, detection, and response provider, released a quick fix that can assist security teams. The existing tool's effectiveness has its limits (it does not work for versions before 2.10) and when it does run properly, vulnerable code remains. However, consider it a very clever option of last resort.
Many organizations are currently struggling to uncover where Log4j exists in their environment and updating a component like this necessitates a dependency analysis, so a system does not get broken in the pursuit of fixing the vulnerability. Ultimately, think of Log4j as a "fire and forget" tool aimed at cleaning up anything that may have been missed. It’s not a solution; it’s a workaround with several limitations.
What’s next?
Organizations should start by enumerating where Log4j exists and may exist in their environment and products. Once identified, they need to do regression testing and patching or apply a workaround so that current systems can remain operational. Log4j operates as a common library in third-party software and hardware appliances in the data center, so it’s important to keep a sharp eye out for vendor updates and patch quickly. Once the first pass goes down, it's safe to assume something has been missed, so it’s crucial to revisit the company’s software inventory and take a second look once the team completes initial patching.
It sounds simple enough, but keep in mind that it’s the kind of software that can easily be there without making its presence obvious. For this reason, I expect a long tail of exploitability on this vulnerability. What does this mean for the days and weeks to come?
The Cybersecurity and Infrastructure Security Agency (CISA) recommends having security operations handle every malicious attempt against a known Log4j endpoint treated as an incident, for organizations with this type of capability. Outside of this, blocking malicious http requests with a web application firewall will deter low-skill users of the exploit, and filtering egress traffic from servers and appliances will limit the potential for data leakage and malicious payload delivery.
The time between the release of the Log4j exploit and its use to deploy malware, with significant consequences, does not bode well for many organizations. The current volume of attacks mostly comes from unsophisticated and opportunistic attackers and from vulnerability researchers trying to identify vulnerable Log4j to help. The quieter, but more sinister activity revolves around payload R&D by sophisticated initial access brokers (IABs) and ransomware-as-a-service (RaaS) operators, who have already started to deploy ransomware.
This Log4j vulnerability reminds us that it’s difficult to mitigate open-source code fully. Organizations will succeed based on how well they execute a well-planned strategy.
