Supply-chain attacks take advantage of insecure segments of the supply-chain of a target. An attacker will manipulate the elements used in the production process of the target, and thereby produce a vulnerability. In many modern examples this involves compromising third-party software libraries. This type of attack is increasingly common and capitalizes on the complex nature of today’s development ecosystems.
These attacks prey on “soft” targets, such as open-source communities and smaller companies, which may not have the same investment in security that harder targets do. The vulnerabilities introduced in these systems are then used to compromise the “hard” target.
When it comes to protecting against supply-chain attacks, traditional security solutions have struggled. In this kind of attack malicious software comes from an implicitly trusted third-party source. Software or hardware deliberately procured in this way is not usually heavily scrutinized and is sometimes automatically whitelisted for purposes of intrusion detection or threat analysis. The target has chosen to use third-party software and hardware in their environment for a specific purpose, why would they think it is malicious? If it is accomplishing its primary use most organizations will not pay close attention to all its operations and behaviors. Therefore signature-based malware detection and firewalls struggle to detect/prevent supply-chain attacks.
Supply-chain attacks have featured prominently in media with large incidents such as the Solarwinds attacks making headlines. To illustrate how they work, we will examine the widely discussed Solarwinds attack, the recent PyTorch attack, and Log4Shell.
First, the PyTorch attack. Over the 2022-2023 holiday season, the PyTorch software suite was compromised using an attack vector known as “dependency confusion,” which takes advantage of the default logic used in package managers and build systems. The attacker registered and uploaded a malicious executable file under the name “torchtriton” to the commonly used PyPi repository, masquerading as a benign package. This package had never previously existed on PyPi, and the nightly builds for PyTorch were configured to check PyPi for packages during their build process. Normally, no package named “torchtriton” was found on PyPi and the build process would switch to a private repository that hosted the legitimate package.
During the attack, the build process found the malicious “torchtriton” package on PyPi and incorporated it into the PyTorch nightly build. When users downloaded and ran the package, it stole sensitive data such as SSH keys, git configurations, and lists of local machine users. The data was exfiltrated from the compromised environment through encrypted DNS queries.
See the below timeline of the attack.
- Between Christmas and New Year’s Eve 2022, nightly builds of PyTorch referenced the malicious torchtriton package.
- The rogue torchtriton package was downloaded over 2,500 times, indicating how many systems were potentially impacted.
- Stolen information was sent to a remote server by way of encrypted DNS traffic by the malicious package.
- After the discovery of the fake torchtriton package, PyTorch removed its dependency on torchtriton and replaced it with pytorch-triton, a renamed version of the previous package. They further ensured that they had control of the registration on all relevant repositories.
The PyTorch attack shows how technically simple it can be, even in 2022 or 2023, to execute powerful supply-chain attacks. Some such incidents are significantly more complicated, but complexity is not a requirement.
Next, the SolarWinds attack Timeline breaks down something like this:
- SolarWinds is breached by the malicious actor.
– It is still unknown exactly how Solarwinds was initially breached.
– Zero-day exploitation, brute forcing passwords and social engineering are all suspected. - Malicious actors place software backdoor into the build system for SolarWinds’s “Orion” software.
- The software is disseminated via regular updates to SolarWinds’s customers between March and June 2020, with the backdoor built in.
– Customers include Fortune 500 Companies, US Government Agencies and Universities - Malicious actors use the backdoor they placed in “Orion” to access the networks the affected companies and steal data
- FireEye notices their networks are compromised and reports the breach
The attackers only had to manually gain access to one network, the SolarWinds internal development network, which was part of a large supply-chain. In the end that gave them access to multiple high-value targets. After the fact, it is likely that even if a victim noticed malicious behavior from the Solarwinds software, they would have determined it was a legitimately procured Solarwinds product and then whitelisted it. This confusion is one reason supply-chain attacks are so devious.
Lastly, log4shell. Log4Shell has been identified by some as a supply chain attack, though this may not be completely accurate. Log4Shell was an exploit produced for a vulnerability discovered in the common “Log4j” software library. Many services rely on the Log4j library including the popular web server Apache, video game Minecraft, and the binary de-compilation suite Ghidra. All this software was in some way vulnerable to Log4Shell. This vulnerability does not appear to have been purposely placed by malicious actors, so it is difficult to claim that it was a supply chain attack. The discovery of Log4Shell and its accompanying vulnerability, CVE-2021-44228, was devastating for security. It had existed in some form since 2013 before its disclosure in 2021 but had gone undiscovered as a Zero-day. Although it bears technical resemblance to a supply-chain attack it does not fall strictly under the same description.
Although we may not classify the log4shell vulnerability as a supply-chain attack, the length of time the vulnerability existed is interesting. In a study published by the RAND Corporation in 2017, the average “life” expectancy of a zero-day exploit was found to be around 6.9 years. This means that log4shell existed closer to the upper-range life expectancy, with 25 percent of studied zero-day’s existing for over 9.5 years. The comparison between a normal software vulnerability like log4shell and a supply-chain attack highlights an apparent difference in the length of time they exist. Although the supply-chain attacks mentioned above do not make up a truly adequate sample size, their relative lack of longevity would suggest a correlation.
All these attacks show that the impact of a cyber-attack is felt even by those not directly compromised. Although vulnerable end-users made no active mistakes, they were put at risk because they used insecure software. Their trusted software was becoming malware or easily exploited by malware without their knowledge. This situation is difficult for traditional security solutions to protect against.
To avoid falling victim to a supply-chain attack, organizations must scrutinize products received from third-party vendors to the best of their ability. Additionally, understanding the possible weaknesses in your own supply-chain is crucial. In an ideal world, all companies would have time and resources enough to conduct thorough testing and analysis of all products they acquire. However, this resource intensive process is not feasible in all instances.
Another option is reducing reliance on supply-chains in general. This solution is a resource intensive and often impractical, though effective. It is worth consideration if iron-clad security is a top priority. In the complex environment of modern business, technology supply-chains are difficult to keep at a highly secure standard.
Despite all these defenses, incidents are still possible. Having a robust and updated software manifest is another crucial piece of supply-chain defense. When a supply-chain is compromised, being able to determine if it does or does not affect your organization is necessary. Such a manifest is a good consideration in relationships with software vendors as well. Understanding the supply-chain of the tools you purchase is just as important as knowing the tools themselves. Requesting a Software Bill of Materials (SBOM) is never a poor decision. This combined with effective end point security will go a long way toward ensuring supply-chain attacks have minimized effect.
To mitigate the threat of supply-chain attacks, organizations can bolster the scrutiny of their acquisition processes, reduce the necessity of third-party tools, and increase their endpoint security. Having good accounting of what software is extant in your ecosystem is crucial for addressing alerts as they arise. For many, one of the simplest solutions will be endpoint security focusing on behavior-based detection. When security tools analyze the behavior of software on a system, agnostic of what the software is, malicious behavior itself can be pinpointed and prevented. As supply-chain attacks become more prevalent, taking these steps is imperative to ensure continued operational ability.
Referenced RAND study:
Zero Days, Thousands of Nights: The Life and Times of Zero-Day Vulnerabilities and Their Exploits | RAND