Two members of the cybersecurity community, Beau Woods and Adam Bregenzer, have developed a new open-source search tool to help cybersecurity professionals navigate an increasingly cumbersome list of software products affected by the Log4j vulnerability.
In the weeks following the disclosure of the flaw, the Cybersecurity and Infrastructure Security Agency quickly moved to put together a GitHub page compiling a list of software products, both those that were known to contain the underlying corrupted Apache code as well as those where it was absent.
That database, which built on the initial work of outside experts like the U.K.’s Kevin Beaumont and French security researcher SwitHak, has fast became a go-to resource for both federal agencies (who were mandated to use it as a reference point for mitigation activities in an emergency order issued before Christmas) as well as industry to cross-check their own IT environments and stay up to date on the scope of Log4j’s impact.
That very popularity has led to some interoperability issues, as the original list has now ballooned to at least 2,858 separate products.
Woods, a fellow with the Atlantic Council’s Cyber Statecraft Initiative who also acts as an advisor to CISA on cybersecurity issues, told SC Media that the repository remains a great resource, but one that has become progressively harder to use as defenders continued to scope out the impact across the broader IT ecosystem.
“Pretty quickly the list started getting really, really big because of the research agencies were doing…and CISA was doing. Once it crossed 1000 individual affected products, that got pretty unwieldy to go through manually to search, there were limitations on how many lines GitHub can display,” Woods explained. “I kind of looked at that and said there’s got to be an easier way, there’s probably some really quick code that could be written to parse this…into a more elegant, tabular form that can hold all of the rows that are created.”
Woods said the search index tool was part of a personal project that he and Bregenzer undertook to help improve the searchability of the database and is not an official CISA project, though a link to the tool has been added to CISA’s GitHub page for Log4j.
From the beginning, one of the biggest challenges that organizations have faced mitigating Log4j has been finding it. The flaw, a logging component in a popular piece of open-source Apache software, is both widely used and deeply embedded in consumer and enterprise IT environments. Because of it is so popular and code re-use is so common throughout the software development ecosystem, most vendors were unable to determine how many of their products use Log4j, while organizations were forced to scour their own IT environments for signs of the bug and exploitation.
That lack of visibility (as well as indicators that malicious hackers were also racing to exploit the vulnerability) is what has prompted a massive, collaborative effort across government and industry to determine the scope of collective exposure. It’s also led to concerns among policymakers about the long tail potential of Log4j and its impact for years to come.
Following a briefing from CISA officials this week, Senator Gary Peters, D-Mich., who chairs the Senate Homeland Security and Governmental Affairs, said he was worried that the federal government and critical infrastructure would be suffering fallout from the vulnerability for years to come. He also called for Congress to pass incident reporting legislation that was dropped from the defense authorization bill at the last minute.
“I remain concerned that we will likely never know the full scope and impacts of this widespread vulnerability, or the risk posed to critical infrastructure,” Peters said in a statement Wednesday. “Our federal government still lacks the necessary insight to understand the threat facing our nation, protect our networks, and impose consequences on malicious hackers.”
Woods also took the opportunity to stump for the development of a Software Bill of Materials (or “SBOM”), essentially an ingredient list that can detail the provenance of different pieces of code, where they came from and help determine whether they’re affected by embedded software vulnerabilities like Log4j.
Woods said around this same time last year, he was working to help identify and locate instances of another major software vulnerability, a corrupted update of SolarWinds’ Orion software. He believes next year he will likely be in a similar situation, tracking down the latest devastating needle in the haystack. Concepts like SBOM, while not a panacea, are critical to avoid repeating the same exercise over and over again each time a deeply embedded software vulnerability is discovered.
“It’s an idea whose time has come, to be able to root out potential issues like this. This won’t be the last one [and] it’s part of a bigger overall ecosystem of security practices,” Woods said. “Having worked in operational roles in the past, even if I know 50% or 80% of my attack surface…an SBOM can go a very long way.”
