Software Supply Chain Attacks

Software supply chain attacks have been all over the news lately. What are they, how did they first rise to prominence, and why are they so dangerous? This blog answers these questions and also provides tips to strengthen your software supply chain.

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.

Why Are Software Supply Chain Attacks So Dangerous?

Software supply chain attacks exploit the trusted relationship between companies and software vendors to gain privileged and persistent access to victims’ networks. These types of attacks are able to access more sensitive data for longer periods of time without their victim’s knowledge than other types of breaches, making them particularly disruptive and destructive.

The National Institute of Standards and Technology (NIST), an agency of the U.S. Department of Commerce, believes these attacks are potentially so harmful that it recently released a report titled Defending Against Software Supply Chain Attacks. Organizations are susceptible because many third-party software products require both privileged access and frequent communication between the vendor’s and customer’s networks.

When it comes to granting privileged access, customers often accept third-party software defaults without a second thought as to what systems and networks are being impacted – and what data is stored there. Malware or vulnerabilities inserted here could give hackers privileged access to the most critical systems within a network.

Third-party software also communicates regularly with customers’ networks, whether to install updates or fix known vulnerabilities. Malicious actors can exploit this frequent communication to send malicious updates or block bug fixes then later exploit those vulnerabilities.

Supply chain attacks are so dangerous because hackers are able to bypass perimeter security and directly access vulnerable networks through a trusted source. Compromised systems often don’t realize security has been breached until significant damage has been done, such as data or financial loss, monitoring organizations to steal trade secrets, disabling networks or systems, and more.

History of Software Supply Chain Attacks

References to the software supply chain can be found as early as the mid-1980s with papers like Unix co-creator Ken Thompson’s Reflections on Trust, which discussed Trojan Horse attacks. Though Thompson warns, “You can’t trust code that you did not totally create yourself,” his paper focused on the potential for compilers being subverted to add backdoors or malicious logic into systems, not on third-party software. To be fair, software was very different then, computers were loosely connected via dial-up modems, and security often took a backseat to functionality.

Fast forward roughly 30 years and the nature of modern computing is one that is wildly and continuously interconnected and in which security must always be top of mind. As high-profile and extremely lucrative hacks become more common, the consequences of such an attack are becoming more severe with companies being fined and sued and suffering irreparable damage to their brand.

The Target data breach of 2013 brought software supply chain attacks back into the headlines. The breach, which impacted 40 million customers and their credit/debit card information, was carried out via the insecure software of Target’s HVAC vendor. The total cost of the hack was $61 million. Since then, more and more software supply chain attacks have been reported.

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.

Strengthening Supply Chain Security

As the saying goes, an ounce of prevention is worth a pound of cure. To that end, we’d like to offer you a few tips:

• Use only verified package sources.
• Watch your typos to avoid typosquatting attacks.
• Wait until a new package is verified by security researchers before using it.

To learn more about how to secure your supply chain, read our blog Supply Chain Security – 10 Tips That Won’t Slow Development Down or Software Supply Chain Security: The Basics and Four Critical Best Practices.