The Log4J Vulnerability: Explained

On Friday, December 10, a critical (read 10 out of 10) vulnerability was identified related to the Java script upon which many (many) platforms are built. This vulnerability, known as the Log4J vulnerability or Log4Shell, creates a pathway by which attackers can easily and automatically infiltrate a network, resulting in remote control access and leaving the affected servers and networks “open to complete remote control.” It is, as Jen Easterly, the director of the Cybersecurity and Infrastructure Security Agency (“CISA”), “one of the most serious” vulnerabilities she has encountered throughout the course of her career.

This vulnerability is a problem that, despite the prompt release of patches and updates, will not be resolved this week or any time soon. In the best-case scenario, we are still waiting for the fallout from incursions affected during the zero-day attack – whether that be exploitation of sensitive data extracted or dormant malware or portals created during the attack. More likely, this is not a confined or restricted situation: we will see similar or related “bugs” identified (and exploited); MITRE has already identified a second, similar vulnerability (happily only of “moderate” severity).

This is to say that this problem, and associated fall-out, is not going away, and organizational leaders need to understand what happened, why it is so important, and what to do going forward. 

SO, WHAT IS THE LOG4J VULNERABILITY, AND WHY IS IT IMPORTANT?

The Log4J vulnerability is a critical defect and presents an existential threat to the security of any network for three reasons:

1. Log4J (and Java as a programming language) is “ubiquitous” and foundational. Log4J is a logging library utilized by many, many (many) companies;
2. The ease by which this flaw enables remote code execution on an impacted system; and
3. You can’t patch what you don’t know (or monitor).

Let’s address these sequentially. Apache’s Log4J is an open-source logging library used by many enterprises on their networks. Think of it as a foundational cornerstone used and replicated across the individual platforms and customized configurations. While Apple, Microsoft, and Amazon (including Amazon Web Services) all have their own platforms and iterations – they all share this same foundational framework. They are thus all vulnerable – and therefore, the impact of this vulnerability is not restricted to any one enterprise, industry, or region. 

Having illustrated the scope and scale of the issue, it is worth pausing here to explain what a logging library is and how it works within a system. Understanding this will also reveal why this “bug” presents such an existential threat.

A logging library documents and directs how a program runs. It outlines the architecture of a network and the automated directives that the program executes. This allows for code auditing and (notably) a window that programmers can use to investigate, intervene, and correct bugs (oh, the irony) and other functionality issues. Simply put: Logging provides a tool to “read” and correct a program’s run-time behavior. 

That leads us to the second reason the “internet has been on fire” this week. That is the ease with which this vulnerability can be exploited. It is not a case of an action on any user within a network clicking on a spearphishing link or taking any action to “open the doors” to the attack; it is instead a case of the door already being open. It’s not just that the call is coming from inside the house – no one had even to pick up the phone; it is an automatic execution of the existing “lookup” or running programming. An external actor only needs to ping a vulnerable system, submitting a specific HTTP request (see the Minecraft “how to” screen grab) or lookup code that allows entry to the system. The program (keeping true to its programming) then executes on that directive, automating access to the external actor (and any subsequent server as directed). 

 IDENTIFICATION AND MITIGATION

The first step (which consumed the weekend for all IT security people) is assessing whether a system utilizes this (ubiquitous) programming. Keep in mind that this zone of impact is further expanded by the complexity of an enterprise’s network and connected interdependencies. It may not be immediately evident whether a platform’s logging library contains Log4J – as the vulnerable component is instead part of an interdependent integration (#fun).

Where Log4J is used, updates and patches can be deployed to fix the bug. However, patches are only effective going forward – and present no protection or correction on previous incursions; this includes data already extracted or dormant malware now planted somewhere within the system. (See the case of Horse and Barn door; or the Barn with the giant creepy crawly somewhere in the haystack). That is why monitoring (with more monitoring and an extra side of monitoring) is so critical.

That brings us to the third component of the problem. You can’t patch or correct what you don’t know – that includes what you don’t monitor. There are two parts to this. First is to appreciate the complexity of any organization’s system, including the interconnections and interdependencies. It is not just a system’s own built environment – but also all the integrations across vendors. A cybersecurity friend and colleague of mine compared the (sometimes blasé “just patch and move on”) solution to identifying and replacing every flat head screw in your house. So, there is a scale and complexity issue – but also one of the facts that for the most part, many organizations (particularly in the health care space where resources are often already stretched very thin) do not have an adequate information security and defense infrastructure – or practice effective defensive data management. This includes creating and maintaining a Configuration Management Database (“CMDB”). A CMDB of a system, detailing its “owners” and administrator and the system’s architecture, is critical to business continuity and response agility and ensures that unnecessary technical debt (such as unretired sites) are resolved and closed. As cybersecurity leader Daniel Miessler summarized earlier this week: asset management is the center of security.

NEXT STEPS

Continued attacks and identification of ancillary or related “bugs” are expected. There are limited things that one can do when it comes to mitigating the fall out of a “zero-day” attack – but there are essential crisis response steps to keep in mind:

• As stated before, update and patch your network where the vulnerability is identified.  For smaller organizations, this includes coordinating with any vendors and outsources IT providers and referencing the running list of evaluated software maintained by GitHub
• Monitor, Monitor, Monitor
• Suppose you haven’t already – take this as a lesson in the importance of asset management and documentation in preparation for the next event. In short, create and maintain your CMDB as an inventory of your system’s configuration, assets, and technical debts. 

Of course, this is also a pretty extraordinary wake-up call for many leaders for all its universal awfulness. There is nothing like a crisis of this magnitude (including but not limited to subsequent ransomware) to demonstrate how critical information security is to an organization’s continued operations. There are two things that I take away from this (in addition to chickens coming home to roost when it comes to exploitation of open-source resources), and that is this: Information security is a critical, foundational function of any organization in this digital age. An organization’s budget, leadership composition, and governance need to reflect that. Our IT infrastructure is not and cannot remain a black box. Organizational leaders need to understand the architecture, dependencies, and vulnerabilities. The technical experts need to have the authority and resources necessary to inventory said resources and operations – and demystify the process.

Helpful Resources:

• GitHub running list of impacted software
• Video by Cybellum provides the most straightforward, simple, and quickest explanation of Log4J
• The SANS Institute panel on Log4J provides a comprehensive and comprehensible technical breakdown of the vulnerability, its impact, and defensive steps.
• A (super) comprehensive rundown of the Log4J timeline and events (and including that xkcd cartoon)