‘Endemic’ Log4j bug set to persist in the wild for at least a decade, US government warns

Inaugural report from cyber safety panel outlines strengths and weaknesses exposed by momentous security flaw

The ‘Log4Shell’ vulnerability in open source library Log4j has reached “endemic” proportions and the aftershock could reverberate for “a decade or longer”, according to a landmark US government report.

The inaugural report by the Cyber Safety Review Board (CSRB) provided 19 recommendations for how organizations and government agencies can bolster their networks and applications against the threat.

The CSRB was established in February 2022 by the Department of Homeland Security (DHS) as mandated by a cybersecurity-focused Executive Order that was signed by President Biden a year earlier.

The public-private initiative is tasked with reviewing serious cybersecurity events and delivering strategic recommendations to government, industry, and the information security community.

‘Transformational institution’

The Log4Shell vulnerability, which surfaced in December 2021, offers a potent combination of super-criticality – notching a maximum CVSS severity score of 10 – and enormous attack surface given Log4j’s near-ubiquity in providing Java-based logging to myriad applications.

Secretary of homeland security Alejandro Mayorkas said the CSRB was a “transformational institution that will advance our cyber resilience in unprecedented ways”, and its report will help “strengthen our cyber resilience and advance the public-private partnership that is so vital to our collective security”.

Tim Mackey, principal security strategist at the Synopsys Cybersecurity Research Centre, said the report was unusual in providing “a comprehensive review of the impact and root causes of a cyber incident so quickly”.

DON’T FORGET TO READ Prototype pollution in Blitz.js leads to remote code execution

The CSRB report (PDF), published on July 14, said “vulnerable instances of Log4j will remain in systems for many years to come, perhaps a decade or longer. Significant risk remains.”

The Apache Software Foundation, which maintains Log4j, was praised for its “well-established software development lifecycle” and “for recognizing the criticality of the problem” in quickly issuing patches.

The report also hailed the rapid production of effective guidance, tools, and threat information by vendors and governments.

Further down the supply chain, however, “organizations still struggled to respond to the event, and the hard work of upgrading vulnerable software is far from complete across many organizations”.

Moreover, the event highlighted “security risks unique to the thinly-resourced, volunteer-based open source community”, which the CSRB said needed more support from both public and private sector stakeholders.

‘Hard to believe’

The report said the CSRB was “not aware of any significant Log4j-based attacks on critical infrastructure systems”, and that hostile exploitation seemed to have “occurred at lower levels than many experts predicted”.

However, Matt Chiodi, chief trust officer at security vendor Cerby, found these claims “very hard to believe”, noting that – as the CSRB itself acknowledged – organizations are not obliged to report exploitation of serious vulnerabilities.

Chiodi also said the recommendations, which among other things cover mitigating ongoing Log4j risks and migrating to a proactive vulnerability management model, “are too opaque for companies to implement in their current form”.

He advised organizations to get “deadly serious about knowing your assets and moving toward a zero-trust architecture”, noting that “most organizations have terrible asset management practices”, particularly in relation to “homegrown applications in the cloud”.

Mackey, meanwhile, cautioned against “reliance on a commercial vendor to alert consumers of a problem presumes that the vendor is properly managing their usage of open source and that they are able to identify and alert all users of their impacted software – even if support for that software has ended.”

With this in mind, “software consumers should implement a trust-but-verify model to validate whether the software they’re given doesn’t contain unpatched vulnerabilities”.