Software supply chain attacks are among the most insidious cyber security threats facing organizations today.
In a software supply chain attack, malicious actors distribute malware, backdoors, or other code to the vendor's customers through seemingly legitimate software. This kind of attack has become pervasive following the growing trend of application development through assembly of open source programs and other 3rd party software, versus coding customized applications from top to bottom.
The consequences of software supply chain attacks can be far-reaching, potentially affecting all customers of the compromised vendor simultaneously. Let’s examine 13 of the most notorious examples of software supply chain attacks, each demonstrating the significant risks and impacts associated with this growing cybersecurity threat.
The number of software supply chain attacks is clearly growing year on year. According to Gartner, 45% of organizations worldwide are expected to experience a software supply chain attack by 2025, which is triple the number of attacks in 2021. In 2023, the number of victims increased by 15% to over 54 million.
But the numbers themselves don’t tell the story of the underlying heterogeneity between them. A ‘software supply chain attack’ could mean many different types of attacks, caused by zero day vulnerabilities in widely used software, ‘poisoning of the well’ and Github confusion attacks, and social engineering and manipulation of open source maintainer communities that push malicious updates.
A zero-day vulnerability is a security flaw in a piece of software that even the developers who made it don’t know about yet. This type of attack takes advantage of vulnerabilities in software before they can be patched. The phrase “zero-day” means developers have zero days to identify, address, and patch the vulnerability because it has already been discovered by attackers.
Developers often use pre-made components or libraries to build their applications. When an attacker decides to add malicious code to these components, it’s known as “poisoning the well.”
Tactics include:
The tricky part is, because these components are often widely used and trusted, the poisoned version can spread far and wide quickly.
CI/CD stands for Continuous Integration and Continuous Deployment. When an attacker injects malware into the operating system of the CI/CD process and distributes malicious updates of the software, that is an attack on the CI/CD.
Tactics include compromising build servers, stealing credentials, dependency confusion, and script injection.
These types of attacks can be hard to spot because the actions often look legitimate, making it difficult to distinguish between a malicious action and normal development action. In addition, some organizations lack comprehensive logging and monitoring across their entire pipeline, so the CI/CD attacks may go unnoticed.
Open-source projects are particularly vulnerable to software supply chain attacks. Anyone can contribute, and many companies rely on them. In addition, they’re often maintained by volunteers or small teams. An attacker might buy or take over the management of a popular open-source project. Once this goal is achieved, they are free to collect user data, create backdoors for future attacks, insert malicious code, and degrade security features. Because many users don’t regularly audit their dependencies, this type of vulnerability can have a major impact on organizations who rely on open-source software.
Imagine a tiny flaw in a ubiquitous logging library providing hackers complete control over infected devices. That was Log4—a zero-day vulnerability that turned a Java package into a global cybersecurity crisis.
Log4j, also known as Log4Shell, serves as a logging library in Java applications, allowing developers to generate and manage logs effectively.
However, in December 2021, the discovery of a critical zero-day vulnerability within Log4j set off alarm bells in the cybersecurity community.
This flaw, designated as CVE-2021-44228, enabled remote code execution (RCE) through specially crafted log messages, presenting a serious threat to any application or service utilizing Log4j.
Due to Log4j's popular adoption across countless enterprise and open-source software projects, the vulnerability affected multiple systems and services worldwide. Attackers capitalized on this vulnerability, exploiting it to execute arbitrary code on compromised systems.
Cybersecurity and Infrastructure Security Agency Director Jen Easterly said at the time that the vulnerability "is one of the most serious I've seen in my entire career, if not the most serious."
The simplicity with which the exploit could be triggered—through a single crafted log message—underscored the severity of the issue.
Major technology firms, financial institutions, government agencies, and critical infrastructure providers scrambled to assess and mitigate the risk posed by the vulnerability.
Incident response teams worked to patch affected systems, but the pervasive nature of Log4j's integration meant that vulnerabilities persisted long after patches were released.
A single zero-day vulnerability turned a trusted file transfer software into a widespread liability. The MOVEit attack —a SQL injection flaw that compromised hundreds of organizations, is an example of the potential weaknesses that can impact data management tools.
MOVEit, a managed file transfer (MFT) application, is used by organizations for secure data transmission. However, a significant breach in 2023 due to a SQL injection vulnerability exposed sensitive data from nearly 600 organizations, including Chuck E. Cheese, Deloitte, and the Johns Hopkins Health System. This flaw allowed attackers to manipulate and extract data from MOVEit's database.
The SQL injection attack on MOVEit exploited a common web application vulnerability where user inputs are not properly sanitized, enabling attackers to execute arbitrary SQL commands. This type of vulnerability can lead to significant data breaches, as seen in this incident, which affected a wide array of prominent organizations and exposed confidential information.
Organizations affected by the MOVEit breach faced operational disruptions and the challenge of restoring trust with customers and stakeholders. Affected entities had to conduct thorough security audits, remove the vulnerability, and reinforce their security measures to prevent future breaches.
A widely used continuous integration and delivery platform became a security risk for numerous organizations when attackers exploited an authentication bypass flaw.
The JetBrains TeamCity Software is used by many developers and DevOps teams to build, test, and deploy software. In September 2023, attackers utilized a vulnerability (CVE-2023-42793) that allowed unauthorized remote code execution and administrative access. It impacted the integrity of numerous software products and even compromised the development lifecycle for some organizations.
The software is used by companies like Tesla, McAfee, Samsung, Nvidia, HP, and Motorola. After the disclosure of the vulnerabilities, attackers were found to be exploiting it at scale.
The response to the attack included patch development, security advisories, enhanced security measures, and user notification and support. JetBrains continues to proactively communicate with its users about vulnerabilities.
A legacy file transfer service turned into a vector for widespread data breaches when the Accellion FTA attack exploited several zero-day vulnerabilities to compromise sensitive data across numerous organizations.
The most significant and well-documented attacks on Accellion FTA, a legacy file transfer service, began in December 2020. Multiple zero-day vulnerabilities were exploited by attackers, leading to widespread data breaches
The attack on Accellion File Transfer Appliance (FTA) was not the first time Accellion faced security issues.
In 2017, Accellion's FTA faced a critical vulnerability that allowed attackers to execute arbitrary commands. Although this did not lead to a major breach at the time, it set the stage for future exploits. Impacted organizations included Kroger, Singtel, University of Colorado, and the Office of the Washington State Auditor.
The attack underscored the risks associated with using outdated technology that lacks modern security features.
Following the discovery of these attacks, Accellion quickly released patches to address the vulnerabilities and urged customers to migrate to their newer, more secure platform, Kiteworks. In 2022, they reached a $8.1 million settlement over the data breach.
Sometimes, hackers turn trusted e-commerce websites into traps for unsuspecting customers. This can be demonstrated by the Magecart attacks—persistent and evolving threats that exploit third-party JavaScript libraries to steal payment card information during online checkouts.
Magecart, a collective of hacker groups, has targeted numerous e-commerce platforms by injecting malicious code into third-party scripts used on checkout pages. This method allows attackers to skim payment card details directly from customers as they make purchases. The widespread use of these third-party scripts means that countless online retailers might be vulnerable to this type of attack.
The simplicity with which the malicious code can be inserted—by compromising a single third-party library—highlights the significant risk posed to any e-commerce website using these kinds of scripts. Attackers can collect sensitive financial information from many users without the retailers being immediately aware.
E-commerce businesses, cybersecurity firms, and regulatory bodies have been working to combat Magecart's ongoing threat. Measures include monitoring for unusual script behavior, employing content security policies (CSP), and regularly auditing third-party code. Despite these efforts, the decentralized nature of third-party script use means that vulnerabilities can persist.
Organizations affected by Magecart attacks have had to quickly identify and remove malicious scripts, notify affected customers, and strengthen their security practices to prevent future breaches. The ongoing nature of these attacks underscores the need for continuous vigilance and enhanced security measures in the e-commerce sector.
A zero-day exploit in Kaseya's VSA software turned the trusted IT management software into a global ransomware distribution mechanism.
In 2021, the Kaseya VSA software, used by Managed Service Providers (MSPs) for remote management, became the focal point of a major supply chain attack. Exploiting a vulnerability in the VSA software, attackers deployed REvil ransomware to approximately 1,500 organizations across the globe. This incident highlighted the cascading impact of compromising software tools relied upon by multiple service providers and their clients.
The attack affected a wide range of businesses, causing significant operational disruptions and financial losses. It underscored the critical importance of securing remote management tools and implementing robust cybersecurity practices to prevent similar incidents.
Following the attack, Kaseya and affected organizations shut down VSA servers, deployed patches, restored backups, and collaborated with cybersecurity experts to implement multi-factor authentication, conduct regular security audits, and improve overall cybersecurity posture.
In a recent example of supply chain vulnerability, the PyTorch machine learning framework faced a significant attack via a malicious package with a deceptive name.
The PyTorch team discovered a malicious package named ‘torchtriton’ had been uploaded to the Python Package Index (PyPI), utilizing a technique known as “dependency confusion.” This package was configured to steal sensitive system data, which included user information and configuration files. The attack took advantage of precedence rules of PyPI so that it could be installed instead of the legitimate one.
The PyTorch team responded to the attack by removing the ‘torchtriton’ dependency from the nightly packages and replacing it with a safe alternative. In addition, they registered a dummy ‘torchtriton’ package to prevent future attacks. The team recommended users clear their ‘pip’ cache to remove any remnants of the package. PyTorch and other projects have been encouraged to use private repositories for internal packages (and to mirror external packages securely).
A popular Node.js package became a vector for a protest-driven cyberattack when the Node-IPC module was sabotaged with malicious code as part of a political protest against the invasion of Ukraine.
In March 2022, the maintainer of the Node-IPC package introduced malicious code through a module it named “peacenotwar.” The code specifically targeted users inside Russia and Belarus, overwriting files with a heart emoji and placing a message on the desktop that said “WITH-LOVE-FROM-AMERICA.txt”.
Node-IPC Versions 10.1.3 and later eliminated the malicious elements introduced by the maintainer. Users were advised to check their systems for signs of tampering and avoid using the affected versions. Security experts advocated for stricter controls and monitoring of open-source contributions. Developers were encouraged to implement vulnerability scanners to help mitigate the risks of open-source software dependencies.
For nine agonizing months, nation-state actors lurked in the shadows of SolarWinds' Orion platform. When they finally struck, they had backdoor access to some of the most sensitive networks in the world. The SolarWinds incident remains a watershed moment in cybersecurity, underscoring the vulnerability of supply chains to sophisticated nation-state actors.
By compromising SolarWinds' software build process, attackers inserted malicious code into legitimate updates of the Orion platform, enabling widespread espionage across critical networks globally.
The scope and sophistication of the SolarWinds attack were unprecedented. The compromised Orion software updates were distributed to thousands of SolarWinds customers globally, including Fortune 500 companies and multiple U.S. federal agencies, including the Department of Defense, the Department of State, and the Department of Homeland Security. This widespread dissemination enabled threat actors to gain unauthorized access to highly sensitive information and compromise critical infrastructure on a massive scale.
In response to the SolarWinds attack, affected organizations scrambled to identify and mitigate the impact of the compromise. Incident response teams worked tirelessly to remove the malicious backdoor from compromised systems, enhance network defenses, and strengthen cybersecurity postures against future threats. The incident prompted a comprehensive review of supply chain security practices, emphasizing the importance of robust vetting, monitoring, and validation of software components and updates.
A compromised script turned the code coverage tool Codecov into a Trojan horse, siphoning secrets and credentials from countless CI/CD pipelines. Attackers managed to alter the Bash Uploader script, a key component used to collect coverage reports from CI/CD pipelines and transmit them to Codecov's servers. This malicious modification allowed the script to act as a Trojan horse, enabling the theft of sensitive information.
The compromised Bash Uploader, distributed via Codecov's official GitHub repository, introduced a backdoor into thousands of CI/CD pipelines worldwide. Through this backdoor, attackers accessed and exfiltrated credentials, access tokens, API keys, and other critical data. The breach not only compromised the security of numerous organizations but also undermined the integrity of their software development environments.
Detecting the malicious changes in the Bash Uploader script required extensive collaboration between cybersecurity researchers and affected organizations. In response to the incident, there was a widespread push for enhanced security measures. These included stricter verification processes for third-party scripts and increased vigilance in monitoring CI/CD pipelines for unusual activities.
Organizations had to conduct thorough investigations to identify and mitigate the impact of the breach. This incident highlighted the importance of securing the entire software supply chain and prompted many to adopt more robust security practices to safeguard their development environments.
A commonly used desktop app for voice and video conferencing became a vehicle for trojanized updates in March 2023.
3CXDesktopApp, a voice and video conferencing software, provides seamless connectivity for remote teams. However, the discovery of a significant supply chain attack on 3CXDesktopApp put users at risk. This attack involved the insertion of malicious code into the application, leading to the deployment of trojanized updates.
Due to the widespread use of 3CXDesktopApp across various organizations working remotely, the malicious code affected numerous systems globally. Attackers used this compromise to launch multi-stage attacks, potentially gaining unauthorized access to sensitive information and systems.
Following the detection of malicious activity, organizations using 3CXDesktopApp, including technology firms, financial institutions, and government agencies, rapidly assessed and mitigated the risk. Actions included identifying and removing compromised versions of the app, switching to the 3CX web app, and deploying updates and patches.
A simple script meant to ensure browser compatibility became a gateway to scam websites, affecting over 380,000 hosts and proving that even the building blocks of the web aren't immune to cyberattacks.
Polyfill, a technology enabling browser compatibility for web applications, unexpectedly became a vector for malicious activity in this recent supply chain attack example.
This incident occurred after the domain and GitHub account of Polyfill.io were acquired by the Chinese company Funnull in February 2024. The attackers modified the Polyfill script, injecting malicious code that redirected users to scam sites. This code was specifically designed to avoid detection by activating selectively based on factors like device type and time of day.
These compromised scripts redirected users to scam websites.
As of July 2024, hundreds of thousands of websites are still reportedly linked to Polyfill. Some of the sites are connected to large companies like Hulu, Warner Bros, and Mercedes-Benz.
The original creator of Polyfill.io, Andrew Betts, advised all websites to remove references to Polyfill.io due to the security risks.
Cloudflare implemented real-time rewrites of cdn.polyfill.io to their secure version, and Namecheap put the domain on hold. Meanwhile, Google began alerting advertisers about the presence of malicious code.
In addition to these responses, cybersecurity firms updated their threat detection mechanisms to identify and mitigate the effects of the compromised Polyfill script.
In a two-year-long con, a malicious actor infiltrated the open-source XZ Utils project, ultimately planting a backdoor in a tool used by millions of Linux systems worldwide.
Attackers gained trusted access as contributors by exploiting vulnerabilities in the project's governance and security practices. They subtly introduced and maintained a backdoor within the XZ Utils codebase, designed to evade detection and enable remote execution of arbitrary code on compromised systems.
The attack impacted major Linux distributions such as Fedora, Debian, openSUSE, and Arch Linux, raising significant concerns about the security of open-source software and the software supply chain.
Security teams worked to identify and remove the compromised versions of XZ Utils. Organizations like CISA and CrowdStrike issued advisories recommending users to downgrade to earlier, uncompromised versions of XZ Utils. Cybersecurity companies implemented additional monitoring and detection rules to identify and prevent additional exploitation attempts.
In addition, the XZ Utils case encouraged the open-source community and cybersecurity experts to collaborate as they worked to analyze the attack, understand its mechanics, and improve the security practices of open-source projects.
The software supply chain attack examples highlighted, from the Magecart and Polyfill attacks to the more sophisticated breaches like SolarWinds and Kaseya VSA, demonstrate the pervasive and potentially devastating impact these kinds of attacks can have on unsuspecting organizations.
The current, most well-known options of protection against supply chain attacks are mainly pre-deployment mechanisms. This means that they operate on artifacts like images and in Git prior to the code being run or deployed.
These mechanisms are primarily useful for categorizing and cataloging the software running in your stack; but are generally useless for detecting attacks, especially the social engineering attacks and the attacks focused on the CI/CD pipeline. They are somewhat helpful in the case of an attack that relies on a zero day vulnerability, as they could show where you have dependencies on the vulnerable code.
Software Bill of Materials (SBOM): An SBOM is like an asset inventory of all the code and dependencies in your code, in terms of versions, packages, dependencies and trace origins. It’s usually in a file format (e.g. json), and can be helpful with search capabilities, especially when looking for particular vulnerabilities or code.
Software Composition Analysis (SCA): SCA is code scanning, and generally is good at identifying known vulnerabilities in open source and third party code, versions, and other items. This is helpful alongside an SBOM, but is generally used more actively than in an asset inventory, pointing out issues that need to be addressed versus just ‘what’s in the code’.
CVEs: We’ve been using these for years to track, categorize and quantify vulns released in the wild
Artifact Signing: This is a newer technology, and examples include Cosign, which is part of the Sigstore open source project, as well as Notary (also a CNCF project). The idea of artifact signing is that you can cryptographically verify the integrity of a given artifact, package or image, and make sure it hasn’t been tampered with.
Build Agents: Some vendors provide agents that run on the operating system of the CI/CD platforms to try and prevent against attacks that use the tactics of SolarWinds, for example.
SLSA: SCA, SBOMs, artifact signing all roll up into SLSA (Supply Chain Levels for Software Artifacts), which is more of a framework you can follow to get software supply chain security in better state. It suggests ways to create enforceable controls and provides guidelines to follow and protect against software supply chain attacks.
Unfortunately, pre-deployment strategies won’t protect against things like Codecov or polyfill, and even code signing will only tell you a part of the story. If your build system is compromised, without a build agent, you’re in trouble.
To protect against the many different kinds of attacks in the software supply chain, RAD Security has proposed a behavioral standard.
What we propose as a standard for behavioral fingerprints is the following:
To learn more about using behavioral fingerprints versus traditional supply chain security solutions, we recommend checking out the webinar, Mind the Gap: How to Bridge the Remaining Voids in Software Supply Chain Security.