The vulnerability is the most serious and widespread ever. It’s also an object lesson for why software development organizations and their customers should embrace software bills of materials (SBOMs).
It has been less than a week since the world first became aware of a serious and remotely exploitable vulnerability in Log4j, an open-source, Java-based logging framework that is a component of Apache web servers.
Since then, things have moved quickly. On December 10, a proof of concept exploit and reports were released to the public. Reports suggest that attempts to exploit the flaw may predate its disclosure by days. In the meantime, malicious actors were attempting to exploit the flaw and scanning the Internet for vulnerable systems to exploit almost immediately following its disclosure. In recent days, attempts to exploit of the log4j vulnerability have been linked to both state-sponsored hacking groups and to cyber criminal groups intent on installing malware including cryptocurrency miners, botnets and ransomware.
[ Get a free SBOM and full supply chain risk analysis report ]
What it is and how it works
A quick review, if you haven’t been following this story. Log4j is a Java-based logging utility that is part of the Apache Logging Services, a project managed by the Apache Software Foundation. Log4j is used in several Apache framework services.
The vulnerability in question (CVE-2021-44228 aka “Log4Shell”) is a previously unknown (“zero day”) flaw in the Apache Log4j utility. It was made public on December 9, 2021 and can be easily exploited to perform remote code execution. According to reports, the vulnerability affects Apache log4j between versions 2.0 and 2.14.1 and is independent of the underlying JDK version. Essentially, researchers discovered that input sent to Log4j isn’t properly sanitized, such that malformed commands sent using the LDAP protocol can result in a remote and malicious Java class file being loaded and run.
Calling Log4Shell a vulnerability may actually be a stretch, as the feature is working as designed, notes ReversingLabs’ Chief Software Architect, Tomislav Pericin. However, the developers of the module may have erred in enabling the feature by default, and failed to consider all the ways that a malicious actor could abuse the functionality for ill intent. That’s a common problem, Pericin said.
Unfortunately, the flaw is also easy to exploit. According to the published CVE, an attacker who can control log messages or log message parameters on an affected system can use JDNI, a common component, to execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. That’s because JDNI allows LDAP to load classes from remote resources and does not apply security policies to- or otherwise sanitize those requests.
A .003-percenter
The seriousness of Log4Shell can’t be overstated. (But for those who want to try, there’s now a website tracking Log4j memes.) As the folks at Sonatype have pointed out: the vulnerability is just as serious and exploitable as the Apache Struts flaw from 2017. As you probably recall, that flaw gave the world the Equifax breach, as well as a string of attacks on other high profile private and public sector networks. Like the flaw, the log4j vulnerability is trivial to exploit, lowering the bar for bad actors to leverage it.
But log4j is much more widely distributed than even Struts. In fact, Log4j is a component of Struts - and a slew of similar frameworks. As one security expert pointed out, Log4Shell is akin to a “0day cluster bomb:” a vulnerability that creates thousands of other vulnerabilities in downstream applications that use it.
How many of those applications are out there? Sonatype notes that in November, log4j-core, the vulnerable version of the module, was the 252nd most popular component by download volume in Sonatype’s Maven Central code repository out of a total population of 7.1 million artifacts - that’s the top 0.003% percentile in popularity by downloads. More than 1,600 software packages have been identified that are potentially vulnerable to attacks targeting log4j. Those include both the popular Minecraft massively multiplayer online game as well as Apple’s iCloud and Twitter. SAP announced on Wednesday that it patched the Log4Shell flaw in 20 applications alone. In the meantime, threat actors are scanning the Internet to identify servers vulnerable to exploitation.
Mitigating the Log4j vulnerability
Mitigating the Log4j vulnerability is accomplished by upgrading to version 2.16.0 of the software, which patches the remote code execution flaw. Speed in deploying the patches is critical, given that scanning and attacks by malicious actors are already being observed. The federal Cybersecurity and Infrastructure Security Agency (CISA) on Tuesday ordered federal agencies to patch systems against Log4Shell vulnerability by December 24, Bleeping Computer reported.
For organizations that are unable to apply the updates, attacks and malicious behavior targeting Log4j can be mitigated by setting system property "log4j2.formatMsgNoLookups" to “true.” In releases prior to Version 2.10, organizations can also mitigate threats by removing the JndiLookup class from the classpath.
Log4j and the case for SBOM
If nothing else, the Log4Shell and the difficulty that organizations are encountering determining whether they may be vulnerable to it makes a(nother) strong case for software publishers and their customers to consider implementing software bills of materials (SBOM).
Software bills of materials function as lists of “ingredients” for applications: identifying the components used and dependencies in complex applications. “SBOM is the essential way of knowing about dependencies in software packages,” said Pericin. And, given the attack on SolarWinds and the Biden Administration’s order for federal agencies to publish “minimum elements for an SBOM” for federal systems, he expects SBOM use to become mandatory in the months and years ahead.
“The key value (of SBOMs) is the ability to create a software inventory so that when an attack or vulnerability like (Log4j) happens you have a place where you can ask (the) question ‘where is it located?’,” ‘where can I get an update?’ ‘What do I have to take offline?’,” Pericin said. Of course, the devil is in the details. Pericin notes that many SBOMs are still manually created and managed. Given the frequency of software changes and the quantity of applications, it can be difficult for individuals to maintain and keep SBOMs up to date.
Companies are bringing new approaches and technologies to the SBOM problem. ReversingLabs, for example, created an SBOM tool that can both generate, inspect and validate SBOMs as well as monitor SBOMs for changes or updates to identified components. “SBOM will help us identify the critical stuff,” Pericin said. “That might lead to better security budgets for these components. It also might lead to fragmentation in the components as people mitigate their risks by using more, different libraries.”
SBOMs aren’t perfect, Pericin notes. Elements like niche libraries and software components that aren’t known to the creators of the SBOM may get overlooked. Log4j, however, would almost certainly turn up on an SBOM and provide a ready map for organizations to look across their entire software inventory and understand where they are vulnerable to attack. Remediating the vulnerability then becomes an easily quantifiable and manageable problem, rather than a mad scramble.
In the meantime, Pericin said organizations face a daunting challenge to keep attackers at bay and the likelihood of months of attacks targeting the flaw. “We’re going to be patching this for months. The problem with these transient dependencies is that you might not be aware you’re using Log4j, and without an SBOM it's going to be hard to figure that out.”
