The Department of Homeland Security’s Cyber Safety Review Board has reiterated what Microsoft warned about the Log4Shell vulnerability in January 2022, that it may take several years to get rid of the security gaps arising out of the vulnerabilities discovered late last year.
The Department of Homeland Security’s Cyber Safety Review Board (DHS CSRB) warned that the ubiquity of Log4j, the Java-based open-source error-logging framework that was afflicted with several vulnerabilities last year, will make it difficult to plug the holes for up to a decade or longer.
CSRB, which was formed recently under the Biden administration, termed the Log4Shell an endemic vulnerability given that Log4j is an integral part of the internet infrastructure. It is used by thousands of companies in web servers and applications, industrial control systems, and several other electronic use cases.
Log4Shell flaws were discovered in November 2021 and disclosed on December 10, 2021. The three vulnerabilities enable unauthenticated remote code execution (RCE) and could allow hackers to take control of the vulnerable target system.
Several exploitation attempts have so far been made by threat actors leveraging Log4Shell. These include dropping remote access trojan (Orcus), Cobalt Strike (a popular attack simulation tool), deploying cryptocurrency miners, ransomware, botnets such as Mirai, and reverse bash shells (to carry out any attacks in the future). Hackers have also exploited the flaws to carry out credential theft.
Terry Olaes, director of sales engineering at Skybox, told Spiceworks, “Cybercriminals were swift to weaponize this critical remote code execution vulnerability when it was disclosed back in December, with far-reaching consequences.â€
“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.â€
When the vulnerabilities were discovered, the director of the Cybersecurity and Infrastructure Security Agency (CISA), Jen Easterly, called Log4Shell “one of the most serious I’ve seen in my entire career, if not the most serious,†a concern shared by 64 Industry experts and reporters.
“Log4j is one of the few pieces of software that’s ubiquitous and appears in popular applications such as Apache Struts, ElasticSearch, Redis, Kafka, and many others, so it’s not surprising to see the CSRB label this an ‘endemic vulnerability’,†opines Matt Chiodi, chief trust officer at Cerby. “Software vulnerabilities will be with us forever. They’re not going away.â€
Chiodi, who formerly served as the board VP and governor of InfraGard (an FBI-private sector partnership for the protection of critical infrastructure), is a tad skeptical. He adds, “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).â€
Indeed, CSRB noted how the exploitation of Log4j has so far been at lower levels than many experts predicted. “Remember, there is no duty to report; therefore, this finding is an educated assumption, and organizations should not feel comforted by it,†he told Spiceworks.
CSRB’s inaugural report is based on the panel’s discussions with 60 organizations from multiple industries (cloud and mobile services providers, critical infrastructure operators and maintainers, cybersecurity service providers and researchers, foreign government cybersecurity organizations, open source software foundations and developers, product developers; the media, the federal government as well as foreign governments.)
See More: Exploitation of Log4j Flaws May Continue for Years, Microsoft Warns
Chiodi believes sub-par asset management practices are why vulnerabilities such as Log4Shell exist. “If you don’t know what you have, you can’t possibly secure it,†he explained.
Chiodi further added, “Asset management is extremely hard, especially when you factor in cloud applications. When it comes to your own homegrown applications in the cloud, developers rarely keep track of what software components they use. For SaaS applications, you need to count on the vendor knowing what they’ve developed and which software components are being used. This is all about software supply chain security, which is broken today.â€
Tim Mackey, the principal security strategist at the Synopsys Cybersecurity Research Centre, has previously written for Spiceworks about reevaluating the “blind trust†organizations place in open source software. Open source is the bedrock of some of the most efficient and effective systems, but it depends on the developer.
“Open source software is fundamentally managed differently than commercial software, but open source software plays a key role in the success of commercial software,†Mackey told Spiceworks.
“Given the management of open source software is different than commercial software, and open source powers commercial software, 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 patch management being a challenge at the best of times, to mitigate the risk of unknown open source governance within vendors, software consumers should implement a trust-but-verify model to validate whether the software they’re given doesn’t contain unpatched vulnerabilities.â€
In the report, CSRB outlined recommendations for affected parties, which echoes what Mackey told Spiceworks. These include vigilance, implementing best practices, and calling for a fortified software ecosystem.
Mackey assessed that the long-term threat from Log4j vulnerabilities is similar to “countless past vulnerabilities,†and that it “favors attackers since their success is based on having at least one victim who hasn’t patched their systems.â€
Olaes added that organizations cannot patch all systems and should minimize the attack surface by prioritizing. He told Spiceworks, “In the years ahead, threat actors will innovate new and creative ways to exploit common tools like Log4j. As a result, preventing breaches requires immediately minimizing your exposure through smart and targeted mitigation.â€
“For a widespread vulnerability like Log4j, 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.â€
Prioritization should, according to Olaes, entail business and financial impact assessment, exposure-based risk scores, exposure analysis, path analysis, and instituting a mature vulnerability management program.
Like Mackey and Olaes, Chiodi also suggested greater rigor in asset management. However, Chiodi said it wouldn’t be prudent for organizations to simply accept the incoming exploitation attempts and called CSRB’s recommendations “good anecdotes†but “too opaque for companies to implement in their current form.†Chiodi firmly believes Zero Trust is the way to go.
He shared an anecdote of his own: “A few years back, the term ‘assume breach’ was popular, but it’s waned. I remember talking to one of my bosses years ago about this; he was dead set against it. He said, ‘That’s admitting defeat. We should be better than that’.â€
“Well, he was wrong. We had small-scale breaches on and off. If every application and system was built with an assumed breach in mind–do you know where they would end up? Zero Trust. This is the answer, but it takes time to implement.â€
Let us know if you enjoyed reading this news on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We would love to hear from you!