Software supply chain takes center stage

Among the many, hilarious memes that circulated in the wake of the disclosure of the devastating remote code execution (RCE) vulnerability in the Apache Log4j software library, one of the most shared is a cartoon from xkcd It depicts a complex looking hulk of machinery labeled “All Modern Digital Infrastructure.” The weight of the entire contraption rests on a tiny, domino shaped piece labeled “A project some random person in Nebraska has been thanklessly maintaining since 2003.”

That is the realization that dawned on many organizations this year, as a string of serious vulnerabilities in common proprietary- and open source software components shook the security of both public and private organizations to their core.

Log4j is the latest and best example of this phenomenon. It is an open source logging library that is relied on by thousands of proprietary and open source applications worldwide. Disclosure earlier this month of a “10 out of 10” severity remote code execution flaw, dubbed Log4Shell, in the library set off a scramble to identify and patch the flaw.

Log4j and CodeCov: Lay bare supply chain risks

Log4j is just the latest in a string of cyber incidents tied to shoddy software supply chains. It appeared almost a year to the day after the initial disclosure of a compromise of SolarWinds, the software management vendor that fell victim to state actors. ReversingLabs extensive analysis of that attack shows how SolarWinds’ Orion software build- and code signing infrastructure was compromised.

By April, we learned of a compromise of the software vendor CodeCov, which disclosed that, beginning in late January, malicious actors gained control over- and made unauthorized alterations to the company’s Bash Uploader script. Those changes enabled attackers to potentially export information stored in users' continuous integration (CI) environments to a third-party server outside of Codecov’s infrastructure. As we noted, the attack revealed gaps in the kinds of security checks that CodeCov (and many other software publishers) do on software updates before release.

Then, in July, ReversingLabs researcher Karlo Zanki disclosed a threat he discovered after a routine security scan of the NPM open source package repository. The malicious code was buried in several versions of the nodejs_net_server package, disguising an instance of the ChromePass utility, a tool which can be used to recover passwords stored inside of a Chrome web browser. That discovery is eerily similar to one we made in another NPM repository back in 2019, when the password “recovery tool” WebBrowserPassView was discovered hiding in an NPM package named bb-builder.

Hacker eye on the software release guy

Behind each of these incidents is a larger trend: threat actors target deployed applications and services, but also the infrastructure that supports them: software release, deployment, and management processes.

The reason for this evolution in attacks is self-evident: protections for software supply chains are few and weak, compared with those used to shield traditional IT environments and deployed web applications. Low-level software components - often the product of open source projects - can provide the means to infiltrate development organizations and subvert the release process itself. And, once attackers successfully infiltrate a development, build or release process, they can exploit the trust granted to that application within customer environments, effectively “hiding in plain sight.”

Lessons for 2022 and beyond

As we noted in our analysis of SunBurst, the next generation of compromises are less about “brute force” and surprise than access, sophistication and patience. Tools from firms like ReversingLabs can help both software publishers and their customers become attuned to supply chain risks: inspecting the discrete software components that make up modern applications for signs of tampering and malicious components such as backdoors and malware.

Likewise, increased adoption of software bills of materials (SBOMs) by publishers provides a road map for internal security teams to address supply chain risks as they arise. President Biden’s Executive Order in May 2021 called on NIST to develop guidelines for federal agencies to comply with the software supply chain provisions of the EO. Among those requirements are that comprehensive and current SBOMs are available for “all classes of software” used by the federal government, including purchased, open source and internally developed software. Once finalized, NIST’s guidance should provide a clear roadmap for both private and public sector organizations to adopt SBOMs and software supply chain security practices.

ReversingLabs has unmatched expertise in malware analysis and software supply chain risk. We’re thinking about the big challenges that lay ahead in 2022 and look forward to discussing our viewpoints and helping our customers and the larger IT community reduce organizational software supply chain risks.

Don’t hesitate to contact us if you’d like to learn more. You can use the button below to schedule a meeting!