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, 2021, 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
Eric Byres
CEO, aDolus Technology Inc.
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 (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 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.
The following VEX documents have been provided by vendors. Review these to see if the products you are using are affected by Log4Shell.
Rod Campbell
Chair, aDolus Technology Inc.
The aDolus FACT platform provides continuous visibility and risk intelligence on the software supply chain. Its AI-powered aggregation, correlation, and analytics engine enables regulatory compliance and provides actionable insights to secure critical systems.
One of the world’s leading manufacturers of industrial gas turbines with more than 16,000 units installed in 100 countries needed to provide evidence to customers that they had checked the security of every component of their software stack before it was deployed to a platform.
Critical, widespread vulnerability is found in the wild and announced to the IT & OT community
aDolus FACT platform scans 35M files to locate and reveal Log4j vulnerabilities in OT software packages
aDolus FACT confirms there are NO exploitable instances of Log4j in this manufacturer's products
VEX documents are generated to accompany SBOMs and streamline the response
This manufacturer quickly alerts customers: there are NO exploitable instances of Log4j in their products
aDolus FACT provides ongoing protection of software supply chain for the next Log4j
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.
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!
What's the Deal with the Log4Shell Security Nightmare?
This is an excellent layman's overview of the situation.
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.
Apache Log4j Vulnerability Guidance page
CISA is updating this webpage as they have further recommendations.
Need help producing VEX documents?