Visibility key to Log4j response

Following on the December 2020 revelation of the Solar Winds software supply chain hack by Russian operatives, 2021 was not to be outdone, with December 2021 marking the discovery of Java developers' “own goal” on the global IT/OT infrastructure.

About a decade ago, contributors to release 2 of the Apache Foundation’s open source Log4j software thought it would be a neat idea for the message/event logging software to be able to send a log that would also execute code, explains Eric Byres, CTO at aDolus (www.aDolus.com).

“Effectively, the Log4Shell vulnerability in the Log4j library provides a way to bundle a command into a message that looks like an event log, send it to your potential victim’s log collector, then initiate a takeover,” Byres explains. The Log4j vulnerability is of particular concern because its use is extremely widespread, the exploit is trivial, plus it’s used in very high level, mission-critical servers. “It’s Solar Winds without the Russians,” Byres adds.

On a positive note, few level-one industrial controllers are likely to be directly compromised by the vulnerability since they don’t do much logging and usually aren’t programmed in Java. But applications at levels two through four—HMI software on up—are another story entirely.

"At this time, we have not seen the use of Log4Shell resulting in significant intrusions,” said Jen Easterly, director of the U.S. Cybersecurity and Infrastructure Security Agency (CISA), at a Jan. 10 press briefing. “This may be the case because sophisticated adversaries have already used this vulnerability to exploit targets, and are just waiting to leverage their new access until network defenders are on a lower alert.”

Because Log4j is a piece of open-source code that developers routinely embed in a larger piece of application software, its vulnerability has shined new light on the chronic need to better manage software development supply chains. The increasing use of software bills of materials (SBOM), which essentially list all software componentry embedded in a particular application, are an important first step to determining if Log4j is present in an application. “For a current product, it’s relatively straightforward,” Byres notes. “But what if it’s a product that’s even five years old? Vendors are as blind as the asset owners as to where the bug of the week might be.”

Further complicating matters from a practical perspective, “The presence of a vulnerability does not equate to exploitability,” says Ron Brash, VP of technical research and integrations at aDolus. He estimates that only 10-20% of vulnerabilities are exploitable. “In order for the vulnerability to be exploitable, the attack packets have to be able to get to it,” Brash says. ”And if the vulnerability isn’t exploitable, leave well enough alone—every patch is a risk and every change needs to be managed.”

   To help address and manage these issues, aDolus is participating in an industrywide effort to develop application-specific Vulnerability Exploitability eXchange (VEX) documents that complement SBOMs by adding a measure of risk assessment to the unfiltered list of vulnerabilities that the SBOM represents. “The thought behind VEX is a standard, machine-readable way for vendors to tell their customers which vulnerabilities are actually risky—and which ones aren't,” Byres says.

Meanwhile, Brash and Byres recommend that asset owners concerned about the Log4j vulnerability consult their software suppliers to determine if vulnerable versions of the library are included in their applications. If that pursuit proves unproductive, aDolus has already tested many applications for Log4j using AI-assisted methodologies and has generously offered to share its knowledge of what OT applications include Log4j—or scan yours if they haven’t already—free of charge. They’ve also established a useful resource page on the Log4j issue at adolus.com/vulnerabilities/log4j/.

Stay vigilant, my friends.