Log4J at 1: A third of downloads still vulnerable to RCE
A year after a critical vulnerability in a ubiquitous piece of open source software, Log4J, set off what The Stack described at the time as an “internet cluster bomb”, nearly 40% of downloads of the popular open source java logging library are still of the vulnerable version – despite the high profile security flaw having been abused in huge numbers of attacks on software and IT infrastructure, including as recently as last month by a nation state.
That’s according to Sonatype which operates a dashboard that visually tracks downloads of the software. To CTO Brian Fox that’s a reminder that it’s “imperative that organizations recognise most of the risk involved with open source lies with consumers, who must employ best practice instead of blaming flawed code. Log4j is not an isolated incident – 96% of vulnerable downloads of open source components had a fixed version available.”
The Log4J anniversary today deserves a moment’s reflection. The acute remote code execution (RCE) vulnerability in Log4j versions 2.14.1 and below (CVE-2021-44228) triggered what one security company, Check Point Research, describes as a “pandemic-like spread of attacks”. It recorded almost 200,000 attempts to exploit the vulnerability within 24 hours of the initial disclosure. (Whilst publications like the FT would claim “more than 1.2 million attacks within a week” many of these were automated scans for the bug rather than actual effective attacks.)
As security firm Sophos noted a month after the vulnerability had first landed, for all those scans, it did not ultimately result in the rapid and automated mass exploitation many feared. (Sophos cited rapid reaction by the security community and the need to customise the attack to each app containing the vulnerable code). Attacks did happen at scale however. VMware customers were among those particularly hit. A month after the Log4J vulnerability was disclosed, a sample of 180 Horizon servers revealed that 10% had been backdoored.
Deryck Mitchelson, Field CISO at Check Point said: “Log4j was a game changer due to how easy it was to compromise, with a single line of code and millions of services and devices around the world that were vulnerable. It is estimated that 1 in 10 corporate servers were exposed. I think it was a wake-up call for an industry that was relatively blasé around the management of open-source libraries and their use therein and were perhaps too trusting of their vendors and the supply chain’s vulnerability management capabilities.
He added: “When managing services as an operational C-Suite leader, vulnerability management was critical to my business continuity, particularly in healthcare. However interestingly, not all vendors were vulnerable to Log4j, and while some vendors stepped up and provided patches very quickly, others were days and weeks behind. It does make you think, does your vendor take your security as seriously as you do?”
Log4J anniversary: Consider using S2C2J Framework
Regulators are now calling for broader use of Software Bill of Materials (SBOM) use by software vendors that lets users understand what open source or other components their software is built with. Industry is resisting.
As Security Week's Ryan Naraine reported this week: “lobbying outfit representing big tech is calling on the federal government’s Office of Management and Budget (OMB) to ‘discourage agencies’ from requiring SBOMs, arguing that ‘it is premature and of limited utility’ for vendors to accurately provide a nested inventory of the ingredients that make up software components. The trade group, called ITI (Information Technology Industry Council), counts Amazon, Microsoft, Apple, Intel, AMD, Lenovo, IBM, Cisco, Samsung, TSMC, Qualcomm, Zoom and Palo Alto Networks among its prominent members. In a recent letter to the OMB, the group argues that SBOMs are not currently scalable or consumable. ‘We recognize and appreciate the value of flexibility built into the OMB process. Given the current level of (im-)maturity, we believe that SBOMs are not suitable contract requirements yet. The SBOM conversation needs more time to move towards a place where standardized SBOMs are scalable for all software categories and can be consumed by agencies,’ the ITI letter read.”
Whilst industry and regulators thrash it out, companies consuming a lot of open source software could consider adopting the Secure Supply Chain Consumption Framework (S2C2F), which Microsoft has been using since 2019 to help ensure that developers are securely consuming and managing open source software at the company. Redmond made it public over the summer and the S2C2F has now been adopted by OpenSSF.
As its authors note: “There are a myriad of ways that developers consume OSS today: git clone, wget, copy & pasted source, checking-in the binary into the repo, direct from public package managers, repackaging the OSS into a .zip, curl, apt-get, git submodule, and more. Securing the OSS supply chain in any organization is going to be near impossible if developer teams don’t follow a uniform process for consuming OSS. Enforcing an effective secure OSS supply chain strategy necessitates standardizing your OSS consumption process across the various developer teams throughout your organization, so all developers consume OSS using governed workflows”.
As the framework notes: Some organizations may attempt to secure their OSS ingestion process through a central internal registry that all developers within the organization are supposed to pull from. However, what if one developer chooses to pull straight from pypi.org or npmjs.com? Is there anything preventing them from doing so? A central internal registry also has the problem of requiring a team to manage the process and workflow, which is extra overhead. As such, the S2C2F tools were developed to secure how they consume OSS today at scale without requiring a central internal registry or central governance body.”
