Log4j Flaw Is 'Endemic,' Says Cyber Safety Review BoardSoftware Bill of Materials Among Recommended Mitigations
A flaw in ubiquitous open-source logging utility Log4j may plague systems for the next decade or longer, making it an "endemic vulnerability," declared a panel of U.S. public and private sector security experts.
See Also: A CISO's Guide to Communicating Risk
The vulnerability, known as Log4Shell, burst into public awareness late last year when code developer Apache Software Foundation set off a global race between systems administrators and hackers when it fixed the bug.
Despite a flurry of warnings, many systems remain open to hackers exploiting unpatched systems, ensuring that what seemed like a sprint is a marathon.
So far, it doesn't appear Log4Shell has resulted in any significant attacks on critical infrastructure, the board says. "Somewhat surprisingly, the Board also found that to date, generally speaking, exploitation of Log4j occurred at lower levels than many experts predicted, given the severity of the vulnerability."
Still, the board's categorization of Log4j as an endemic vulnerability is not all that surprising, says Matt Chiodi, chief trust officer at Cerby.
Log4j is one of the few pieces of software that's nearly everywhere. It appears in popular applications such as Apache Struts, Elasticsearch, Redis and Kafka, he tells Information Security Media Group.
The CSRB report comes on the heels of a warning by the Cybersecurity and Infrastructure Security Agency and the Coast Guard Cyber Command that advanced persistent threat actors are using the Log4j exploit to hack into unpatched virtual machines (see: Attackers Use Log4Shell to Hack Unpatched VMware Products).
Cybersecurity firm Horizon3.ai detected the exploitation of Log4j in close to a quarter of the environments it was run in. Known vulnerabilities in widely deployed applications such as virtual desktops or wireless access points are just the beginning. "There are probably thousands of Java applications impacted by Log4shell to varying degrees," it says.
One reason for the persistence of unpatched Log4j systems is that most organizations have terrible asset management practices, Chiodi says. "If you don't know what you have, you can't possibly secure it." Asset management is tough, especially when taking into account cloud applications. "When it comes to your own home-grown applications in the cloud, developers rarely keep track of what software components they use," he says.
Supply chain risk also plays a significant role. Vendors don't necessarily know the components of their software.
Among the board's recommendations is greater uptake of software bills of materials -machine-readable lists of the components and dependencies embedded into any application (see: Getting Ready for Software Bills of Material).
Enterprises should implement secure software practices, deploy vulnerability scanning technologies and upgrade vulnerable versions of Log4j, it says.
It also encourages enterprises to set up a vulnerability response program and a vulnerability disclosure and handling process and asks the U.S. government to check the feasibility of establishing a Software Security Risk Assessment Center of Excellence in collaboration with the private sector.