Man touch key to unlock binary code showing Log4j vulnerability report by Cyber Safety Review Board

New Cyber Safety Review Board Report: Log4j Vulnerability Is “Endemic,” Expect It To Be Exploited Into the 2030s

The Cyber Safety Review Board, a cybersecurity incident review panel staffed by members from both federal agencies and the private sector, has completed a 40-page study of the Log4j vulnerability that suggests it will be a problem for organizations for a very long time.

The board finds that the open source community is “under-equipped” to fully deal with the Log4j vulnerability and that it will be making appearances in the wild for “a decade or more.” The vulnerability impacts millions of pieces of software and systems around the world, and cannot be neutralized unless an organization undertakes a deep dive into their own network to find all the instances of it that are in place.

Cyber Safety Review Board declares Log4j too big to fully contain

The Cyber Safety Review Board is made up of high ranking members of an assortment of defense and intelligence agencies, along with representatives from Google, Microsoft and several major private cybersecurity firms.

The central finding of the report is that the Log4j vulnerability is simply too widely spread across internet-connected systems to be completely contained. First disclosed in December 2021, the Log4j vulnerability is a critical security flaw in a very commonly used piece of Java logging software that has been in circulation since 2012 and is deeply embedded in millions of software packages. The Cyber Safety Review Board finds that only a culture of “shared responsibility” going forward will provide the means by which to mitigate the damage.

While the Log4j vulnerability is patched with a simple update, the crux of the problem is the lack of a centralized and efficient way to track down all of the software it is embedded in. There is no way to simply issue a central update to all of the instances of it out there connected to the internet; individual system administrators and IT staff have to comb through their organization’s code and manually ensure each instance of it is updated. The other piece of the problem is that the flaw is trivial to exploit once discovered, usually only requiring the attacker to send a relatively simple string of code.

Terry Olaes, Director of Sales Engineering for Skybox, expands on the scope of the threat: “A CISA official estimated that hundreds of millions of devices are likely affected due to its widespread use. Skybox Research Lab has been tracking Log4j since the exploit was publicly released in December 2021, and while the findings of the report are unfortunate they are not surprising given Log4j’s widespread use across market-leading vendors. Log4j threats expose victims that lack mature cybersecurity risk models to attacks that have remote code execution (RCE) vectors like ransomware, and there will likely be many attacks associated with this vulnerability for years to come … patching all of the instances isn’t practical. Not only is it time-consuming, it’s also hugely costly as well. History shows that the ‘patch everything’ strategy is a monumental waste of effort due to the fact that typically it’s a very small subset of devices that are actually exposed to the attack itself. That is why it is crucial to take a more proactive approach to vulnerability management by learning to identify and prioritize exposed vulnerabilities across the entire threat landscape.”

The Cyber Safety Review Board comes to the conclusion that outdated and vulnerable instances of Log4j will continue to be uncovered and exploited here and there for at least 10 years (if not more). Organizations have already burned through considerable resources in addressing the issue; the Cyber Safety Review Board reports that one federal cabinet department spent 33,000 man-hours just on addressing the Log4j vulnerability, which delayed other critical work including regular patching and other necessary elements of cybersecurity defense.

Log4j vulnerability not only a major threat, but a massive drain on IT resources

The Cyber Safety Review Board’s report reviews organizational response to the disclosure of the Log4j vulnerability, and (unsurprisingly) finds that mature cybersecurity programs with substantial technical resources and good documentation of how Log4j is used in their environment fared the best in addressing the issue. However, there were relatively few organizations that found themselves in this position and able to mount an effective response. Most organizations experienced substantial delays, and had to weigh the costs of a focus on patching the Log4j vulnerability against operational disruption and diversion of IT resources needed elsewhere for other important security matters.

One piece of good news from the Cyber Safety Review Board report is that exploitation of the Log4j vulnerability has thus far been relatively “low level.” There have been no known successful attacks on critical infrastructure using this method as of yet, and while state-backed threat actors are making millions of attempts to use it they are meeting with little success thus far. However, that is only good news in the “macro” sense and relative to company size, as John Bambenek (Principal Threat Hunter at Netenrich) notes: “The Log4j vulnerability was first widely known in December. This report is eight months after that. At this point, anyone still vulnerable is highly unlikely to read this report or be in much of a position to do anything about it if they did. Most of the American economy is small to medium business who almost never have a CISO and likely not even a CIO. Until we find ways to make the public without security budgets safe, no high level list of best practices will move the ball significantly.”

Matt Chiodi, chief trust officer at Cerby, is also unconvinced by the report’s methodology in this particular area: “I find it very hard to believe that an “endemic ” vulnerability did not prompt any “significant” CI attacks. The CSRB said they don’t have any good way to track the exploitation of vulnerabilities, and companies are not currently required to report (although this is changing) … Remember, there is no duty to report; therefore, this finding is an educated assumption, and organizations should not feel comforted by it.”

Security engineers reported a variety of methods that were deployed successfully in the early days of the response, before Apache Software Foundation patching was complete. One was simply finding every instance of the “JndiLookup.class” file, which contains the Log4j vulnerability, and deleting it. They also configured Web Application Firewalls (WAF) to limit exploit queries, egress filtering of network traffic from systems utilizing vulnerable Log4j code, and physically disconnecting impacted assets from the network until patching could be done.

#CyberSafety Review Board finds that the #opensource community is 'under-equipped' to fully deal with the #Log4j vulnerability and that it will be making appearances in the wild for 'a decade or more.' #cybersecurity #respectdataClick to Tweet

The Cyber Safety Review Board provides 19 key mitigation recommendations given the expectation that the Log4j vulnerability will be an endemic security issue in years to come. It calls for federal and state regulators to implement CISA guidance on the issue as a requirement, improvements to Software Bill of Materials (SBOM) tooling and adoptability, Increased investments in and improved incentive structures for the development of open source software security, and a baseline requirement for software transparency for federal government vendors. The Board also urges enterprise risk management teams specifically to improve visibility into systems, create and clarify vulnerability management plans, and have communications plans in place that address both internal company elements and customers.