Software supply chain attacks are back in the news. Last week, security researcher Alex Birsan executed a novel attack against Microsoft, Apple, PayPal, Shopify, Netflix, Tesla, Yelp, and Uber by leveraging a design flaw in automated build and installation tools. Along with the recent SolarWinds breach, this most recent attack is renewing attention on software supply chain security.
What Is a Software Supply Chain Attack?
A software supply chain attack occurs when a malicious actor gains access to an organization’s system through malware installed on the software of a trusted third-party partner or provider.
In a software supply chain attack, Malicious actors infiltrate a legitimate application then change source code and hide malware in build and update processes with the intention of distributing that malware downstream automatically to a wider audience. In this type of attack, the original victim is not the final target, but rather a stepping stone to many other potential networks. The trusted vendor is unaware that they are sending malicious code to their customers.
These types of attacks work because they occur when users update software built by a vendor that they already have a relationship with and trust. When malicious code is installed on the target organization’s site, it runs with the same permissions as the trusted application. Depending on the popularity of the infected application, software supply chain attacks have the potential to reach a large number of victims.
The SolarWinds Breach
Perhaps the biggest breach of 2020 was a supply chain attack involving SolarWinds’ Orion platform, which monitors network performance, log files, storage, config files, databases, and more. A malicious actor – evidence points to hackers backed by Russian intelligence – injected malware into one of the Orion tools during the build process. That software update was then automatically distributed downstream to Orion customers, including Cisco, Intel, Nvidia, VMware, and numerous US federal government agencies.
This attack was successful and went unnoticed for months because the software update appeared to be legitimate. Updates were signed off by SolarWinds, and customers had no reason to suspect a compromise had occurred. The malware contained in the SolarWinds update opened a backdoor to infected systems, giving hackers access to the infrastructure of any company using the Orion platform. In the SolarWinds breach, the supply chain was the attack vector used to distribute the malware. SolarWinds’ customers, and not SolarWinds itself, were the intended targets.
The Dependency Confusion Breach
The most recent software supply chain attack was the work of researcher and ethical hacker Alex Birsan. In a nutshell, Birsan took advantage of a design flaw in the way open source systems handle dependencies to push malware into targeted systems.
It began when another researcher shared a manifest file, package.json, from an npm package used internally by PayPal. Birsan noticed PayPal’s file contained a mix of public npm and private dependencies. He surmised that the private package names were most likely hosted internally by PayPal because they did not exist in the public npm registry. Birsan wondered what would happen if malicious code was uploaded to npm under the private package names. Would PayPal’s internal projects start defaulting to the new (now malicious) public packages instead of the private ones?
To test his theory, Birsan uploaded duplicate packages to open source repositories including PyPI, npm, and RubyGems. It turned out that if a dependency package used by an application existed in both a public open-source repository and a private build, the public package was given priority and was pulled instead – without requiring any action from the developer. Birsan also realized that in some cases, packages with higher version numbers would be prioritized regardless of whether they were public or private. This allowed Birsan to launch a supply chain attack against multiple high-profile enterprises.
One way to think about this attack is to imagine you’re shopping for cereal. You’re in the grocery store aisle and you reach for your favorite – a box of Lucky Loops in its signature purple box. You toss the box in your cart and head on down to the milk cooler without a second thought. You don’t open the box to check that it actually contains those sweet and crunchy green cereal loops. You just assume it does. Now imagine you get home, open the box, and discover that it contains muesli. This is essentially what is happening in this supply chain attack. Birsan uploaded packages that looked the same on the outside, but contained malware on the inside. Automated build and update tools are designed to look only at the packaging. They’re not looking inside to check the contents of the box.
It should be noted that Birsan uploaded these packages from his own account with the disclaimer, "This package is meant for security research purposes and does not contain any useful code." For his efforts, Birsan earned USD 130,000 from four different bug bounty programs.
The Impact of New Attack Vectors on Open Source
Though Alex Birsan’s software supply chain attack involves open source repositories, it is not directly related to open source code. The attack was more about exploiting how automated build or installation tools install dependencies.
Despite the attention and subsequent fixes raised by these recent breaches, software supply chain attacks are expected to grow, especially on open source platforms still struggling to deal with issues like dependency confusion. Thankfully, malicious open source packages are far less common than accidental open source security vulnerabilities, which are disclosed and announced publicly, usually along with a fix.
As the saying goes, an ounce of prevention is worth a pound of cure. To that end, Microsoft published a white paper that details three ways to prevent this type of breach, which the company calls a substitution attack:
Reference one private feed, not multiple
Protect your packages using controlled scopes
Utilize client-side verification features
The software we use today has become a mix of proprietary, third party, and open source. While we understand the security risks associated with each on their own – and do our best to prevent vulnerabilities through extensive security scanning and testing – we have not yet learned enough about the risks that come with this hybrid approach to software. Until we learn more about the risks inherent to today’s complex software ecosystems, novel attacks will continue to surface.