Anatomy of a supply chain software attack

Software supply chain attacks have been gaining momentum over the past few years, and some large-scale events have made headlines, including those targeting SolarWinds and Kaseya that affected Australian organisations. Following research from Gartner, 45% of organisations worldwide will have experienced attacks on their software supply chain by 2025, a three-fold increase from 2021. And yet, little is being done in Australia to raise awareness of this threat, keeping levels of preparedness to such attacks low among our organisations, with only one-third having assessed the risk of attacks on their software supply chain.

Threat actors are increasingly targeting the software supply chain because of the leverage available from a successful breach, threatening not only the targeted organisation, but also its whole ecosystem. To better protect ourselves, we need a full understanding of the diverse ways these situations can unfold, looking at the anatomy of a software supply chain attack.

New dev environment a catalyst

First we need to understand recent evolutions in application and software development that have become a catalyst for increased pressure on the supply chain.

Modern software development has made the software supply chain more complex. Consumers are putting vendors and developers under pressure to deliver amazing apps, software and continuous updates quickly and reliably. Thus, organisations have created new development processes, including agile development, CI/CD and DevOps to help accelerate pace of delivery and time-to-market. They are also more inclined to outsource elements that are not core to their business, embedding external services such as payment, navigation or speech-to-text, to name a few.

Consequently, the actual code used to build an application is often an assembly of components, including custom code, open source dependencies, build and packaging scripts, containers, or infrastructure provisioning configurations (ie, Infrastructure as Code). The list goes on. These components originate from diverse sources, which sometimes privately host code repositories, but usually come from cloud-based, and even public, sources.

These changes and trends have resulted in extremely complex software supply chains, making them an attractive target for malicious actors.

Supply chain attacks: a means to an end

In a software supply chain attack, threat actors compromise an “upstream” component in the chain with the objective of compromising a “downstream” component. Compromising the upstream component builds a bridge for the attackers to reach their actual target. Any links that are part of the supply chain can be compromised, but most research identifies three culprits: dependencies, pipelines, and pipeline dependencies.

Dependencies: in this type of attack, application dependencies such as open source packages or container images used by developers to build software are compromised. Attackers use different methods to insert malicious code into publicly accessible packages. As a result, malicious code is automatically downloaded by unsuspecting developers using the package.

Pipelines: here the development pipeline used to build and release software is compromised. Attackers inject malicious code into the code that defines the build process, such as CI scripts, build tooling configurations, and infrastructure as code. As a result, the build process itself is compromised and used to distribute malicious code to downstream consumers.

Pipeline dependencies: with this approach, the external dependencies used as part of the build pipeline are compromised. They can be 3rd party plugins, tooling binaries, or the build environment itself.

While a bit old, the event-stream incident shows the way a software supply chain attack can unfold. The event-stream package was a JavaScript toolkit designed to create and manage streams in JavaScript applications. It was used by 1600 packages and downloaded 1.5 million times/week, but had not been actively maintained for about two years. Using manipulation and deception, the attacker managed to gain publishing rights to the package.

They then modified it to depend on another package called flatmap-stream, which was altered to include malicious code. This immediately affected all subsequent downloads of event-stream, which the attacker could have leveraged to compromise more organisations. It turns out their end objective was to compromise Copay, a bitcoin wallet platform that was successfully infiltrated, and cryptocurrencies were stolen. It took a month and a half before users noticed the malicious code, and by that stage, event-stream was downloaded millions of times.

Risk mitigation has to increase

Securing the supply chain is still an active field of research, and different models exist to achieve it. A common trifecta includes: securing code, securing pipelines, and embracing DevSecOps processes.

While I can’t detail these approaches here, I can only urge Australian companies to look more closely at them. The scale of successful software supply chain attacks is usually significant, with the impact felt across a whole ecosystem as opposed to a single company. Mitigating the risk of such attacks should be a priority for any organisation wanting to protect itself — and all of its stakeholders — from cyberthreats.

Image credit: ©stock.adobe.com/au/denisismagilov