It seems like a week doesn’t go by without a new vulnerability demonstrating the fragility of the software interdependencies that make up the software supply chain.
A large part of software development leverages the benefits of open-source platforms and third-party vendors to deliver results on time. A wide range of people and organizations maintain those code bases.
If you consider all the components you need for your software, you have a pretty long chain, and those components have dependencies too. Any weak link can compromise the entire software supply chain, putting your business at risk. SolarWinds and Kaseya are two recent high-profile examples of software supply chain attacks, and both vendors had customers that were compromised as a result. The dependencies and risks are staggering.
Complex Software Dependencies
Modern applications have hundreds of dependencies, including lots of open-source components. As developers we don’t write most of the code used in our software and applications. That can create security risks, as you can’t fully control code you didn’t write and maintain.
You’re safe as long as all dependencies are secure. Unfortunately, unpatched vulnerabilities in software are pretty common, sometimes leading to supply chain attacks when hackers exploit them.
Worse still, even secure vendors can become vulnerable with faulty updates, and that’s hard to detect. With supply chain attacks, hackers don’t need to gain commit access to compromise the codebase. Your CI/CD pipelines will deploy flawed vendor software in production for them.
In the end, it does not matter if the vulnerability has been added on purpose to distribute a security hole or if it’s a silly mistake from an innocent developer. The result is the same.
Also read: SBOMs: Securing the Software Supply Chain
How Hackers Compromise the Supply Chain
This year, Microsoft published a white paper about a new technique called dependency confusion, also known as a substitution attack, focusing on the app-building process in trusted corporate environments.
A project can get its components from multiple sources. There are both private and public code repositories.
If hackers find the name of one of the private repositories, they can register public repositories with the same name and upload their version of what is supposed to be an internal library. The package manager can get confused with the multiple feeds and download the public version instead of your internal repository because the public repository has the highest version number.
Sometimes, you can get the information directly in production, for example:
https://website.com/package.json
The package.json file is where npm or yarn stores the names and versions for installed packages. It should not be web-accessible. Unfortunately, even when this file is not publically accessible, hackers can still get information if developers have forgotten to disable source map files in production. These .map files are usually used for debugging JavaScript and contain several references to the node_modules.
Attackers may use other techniques such as typosquatting. They publish public packages with closed names to popular package names, waiting for developers to misspell a dependency in their package.json or composer.json.
Another known technique is to submit tricked pull requests. Hackers sometimes hide malicious code in apparent legitimate bug fixes. Maintainers may validate those modifications and merge the code into the main branch, resulting in poisoned deployments in production.
However it’s done, compromising update mechanisms is becoming more and more prevalent in software supply chain attacks.
Also read: Top Code Debugging and Code Security Tools
The SolarWinds and Kaseya Attacks
In 2020, sophisticated threat actors successfully compromised Orion, the most widely used SolarWinds product, to deploy malware tucked in an update. The incident has been renamed SUNBURST.
SolarWinds is a prominent actor in network management systems, with hundreds of thousands of customers, including the U.S. Department of Defense. The company’s products automate many activities, such as pushing updates and patches to users. While fewer than 100 installations were ultimately affected, around 18,000 were potentially susceptible to this attack.
By compromising the update channel used by Orion with a malicious digitally-signed .DLL (SolarWinds.Orion.Core.BusinessLayer.dll), hackers managed to exfiltrate critical documents from various agencies and companies.
The .DLL remained dormant for days and then connected to several command-and-control servers to receive additional instructions such as file transfer and system enumeration. Hackers also deployed a custom version of Cobalt Strike onto the targeted machines.
The U.S. Government attributed this activity to the threat actors associated with the Russian Foreign Intelligence Service (SVR). The U.S. Cybersecurity and Infrastructure Security Agency (CISA) directed federal agencies to remove SolarWinds products and investigate.
However, that action didn’t completely eliminate the threat, as authorities couldn’t say whether they eradicated their adversaries or not, making those attackers an advanced persistent threat (APT).
In July 2021, threat actors targeted Kaseya, which provides various IT products, including tools to manage networks and endpoints, compliance services, and automation platforms. Their numerous customers include managed service providers that serve other companies, making Kaseya central in the supply chain.
The REvil threat group exploited a vulnerability in a web interface that allowed for bypassing authentication processes, uploading payloads, and injecting tricked SQL commands remotely. Any client attached to the trusted VSA server executes tasks without raising any alert or asking credentials. That’s why hackers targeted Kaseya.
The ransomware group asked for the equivalent of $70 million in bitcoins to provide a decryptor and allow companies to recover their files. Kaseya had to shut down its servers and warn its customers worldwide. They requested the assistance of CISA and the FBI but the damage was done.
Also read: Best Third-Party Risk Management (TPRM) Tools
How to Mitigate Supply Chain Attacks
Because of the widespread damage a threat group can inflict from a single source, supply chain attacks are here to stay, and the extensive chain of software and IT interdependencies isn’t likely to change either. In one of the few bright spots, one industry observer sees defenses improving, which could help the situation somewhat.
There’s no way you can prevent a supply chain attack from ever occurring, but that does not mean you cannot take preventive measures. Here are a number of actions that can help:
- Have a stricter vendor policy. Don’t source from multiple private registries when you can use only one.
- When you register a private repository, register a public repository with the same name to prevent typosquatting.
- Keep all software up to date, even if the update process is now a risk too.
- Secure all configuration files and never deploy them on production, or, at least restrict their access.
- Be extremely careful with IT management interfaces. Privileged accounts with a super high level of access should be few.
- Have several layers of defense and use monitoring tools such as SIEM or SOAR to detect suspicious behaviors early.
- Segment your networks. Don’t let any breach at a low level expose the whole system.
Read next: Top IT Asset Management Tools for Security
