What is the Log4j (or Log4Shell) Vulnerability?
Log4j is a widely-used software library from the Apache Foundation that shows up in products across a vast array of industries.
On December 10, a serious zero-day vulnerability in Log4j was reported that impacts a dizzying array of potential victims — from Minecraft servers to mobile phones to industrial control systems (ICS).
Log4j's job is to log things — a totally normal, and indeed necessary, task in any software system. And sensible developers the world over included Log4j in their software rather than recreating the wheel with a bespoke logging system. Its very utility is the reason Log4j is so widespread. Unfortunately, this vulnerability allows attackers to write malicious “messages” into a log that could then be used to actually execute code loaded from compromised LDAP servers.
In a nutshell, the Log4j vulnerability (called Log4Shell) is a result of overly-provisioned features that were enabled by default, an insecure default configuration, and the implicit trust of messages. It has received the identifier
CVE-2021-44228.
“Mitigation is impossible if you don't even know if you've got the vulnerability.”
—
Eric Byres
CTO, aDolus Technology Inc.
Challenges Uncovering Log4j
When a high-profile vulnerability like Log4Shell hits the front page, ICS operators want to know immediately if they are affected, because malicious actors are generally the fastest to respond to these events (and the exploits swiftly follow). Unfortunately, it can be difficult to know if you are harboring a vulnerable library like Log4j.
- It can be hidden within another product or nested in a product within another product. This nesting aspect is core to the software supply chain. Rarely is a software package shipped without some 3rd-party software embedded in it.
- Software vendors can usually check if their “in-development” products have Log4j (tools like BlackDuck make that easy). But for software that is already released, or worse, where you have no source code, it is very difficult to check for a specific library.
SBOMs — The First Step in Finding Vulnerabilities
SBOMs (Software Bill of Materials) are the first and best tool in uncovering hidden vulnerabilities like Log4Shell. Vendors need to be fully transparent about the components that comprise their software, including all subcomponents. They can no longer be selective arbitrators of advisory information.
- The FACT platform provides enriched SBOMs that report all the subcomponents of a software package. FACT can create these SBOMs from binaries. (Source Code Analysis is another option if you've got the source code, but that's often not the case in the OT world.)
- FACT's enriched SBOMs show relationships between products and components, so end users and vendors alike can see which vulnerable components affect which products.
VEX Documents and Exploitability — the Next Step
VEX documents are companion documents to SBOMs that allow a vendor to communicate if a reported vulnerability is present in a particular product and if it's actually exploitable. Perhaps a vendor's product uses Log4j but it is using a previous version that is unaffected by the vulnerability. Or the software is configured in a way that makes the exploit impossible. What really matters is if the product you are using can be exploited via the vulnerability. VEX gives you a definitive answer in a machine readable form.
VEX Documents for the Log4j Vulnerability
The following VEX documents have been provided by vendors. Review these to see if the products you are using are affected by Log4Shell.
“The provisioning of SBOMs is now mandatory to do business with the US government; expect the Log4j crisis to drive this requirement further.”
—
Rod Campbell
CEO, aDolus Technology Inc.
Additional Resources for the Log4j Vulnerability
A lot of material has been published in the last96 hourson Log4j. We've curated some of the articles and compiled a list of those we believe to be the most helpful.
aDolus Blog post on Log4j by our own Ron Brash
This infographic from the Swiss government's Computer Emergency response team steps through the actions an attacker would take to exploit the vulnerability in Log4j:
Note that the graphic misses a key point: if you don't know that the software you use contains Log4j, you won't know whether you should patch or block evil traffic, or perhaps do nothing at all!
Lawfare
What's the Deal with the Log4Shell Security Nightmare?
This is an excellent layman's overview of the situation.
Industrial Cyber
CISA warns public, private sector of critical Log4j vulnerability
News Editor Anna Riberio covers CISA's response to Log4j and includes commentary from industry leaders.
CISA
Apache Log4j Vulnerability Guidance page
CISA is updating this webpage as they have further recommendations.
The National Vulnerability Database (NVD) CVE listings
Learn more aboutVulnerability Management
Need help producing VEX documents?