What is a supply chain attack?
This is a type of cyberattack that seeks to damage an organization by attacking weaker elements in the supply chain. A supply chain attack can happen across any industry.
Software supply chain attacks occur when attackers insert malicious code in a poorly secured part of the software supply chain. This causes a ripple effect, in which a lot of consumers of the software are impacted by the attack.
Types of supply chain attacks:
Supply chain attacks can be very versatile. Most frequently, these attacks involve fake updates. Cybercriminals compromise the equipment of an employee, accessing the internal network through the employee credentials. Once inside, the attackers spread infected code through the network.
Another method involves intercepting a file download, adding malicious code to it, and sending it to the target computer. Organizations that don’t use encrypted protocols are often at risk from this type of attack.
In other cases, criminals can access libraries, frameworks, and development kits from third parties. If attackers compromise those, the problem can spread to every application that uses them.
Why do regular security practices don’t work for supply chain attacks?
Recent attacks like SolarWinds and Capital One, show how they can spread quickly and dangerously on widely-used-software.
The issue with supply chain attacks is that a lot of conventional security practices are not effective against them:
- Myth: only install signed versions. This recommendation doesn’t work when the software is signed, as is the case with most supply chain attacks.
- Myth: update your software. This doesn’t help when the infected software is the update.
- Myth: monitor software behavior. Granted, if you continuously monitor behavior, you may eventually detect the problem, but until it does, the attacker may have caused a lot of damage already.
- Myth: review source code. Attackers write the changes to look like the organization’s own source code, so it is difficult to identify it.
Is Linux Safer from a Supply Chain Attack?
It is a common misconception that Linux is invulnerable to cybersecurity issues. However, the attacks of recent years showed that this is not exactly so.
One of such cases involved vulnerabilities discovered in Linux Pling. Cybersecurity researchers discovered an unpatched flaw in Pling open source software marketplaces. This vulnerability means all Pling-based marketplaces have a XSS wormable flaw that attackers can use to modify or add listings to the Pling store.
Linux may still present risks. Although Linux users are very active and patch vulnerabilities as soon as detected, it may be worth it to understand what type of measures Linux is taking to prevent security exploits.
Open source software repositories: You can install two types of software in Linux, open source or proprietary. The code is visible to any user that wants to review it. Using the repository system offers better protection since its content is checked before allowing the download.
Security politics: Some Linux distributions like Debian and Ubuntu take extra measures to review the integrity of each package added to the platform. They also control the number of people that can take care of posting updates.
Anyway, no operating system is secure 100% against user negligence and errors. When users install programs from unknown sources, or enable permissions’ misconfigurations, Linux can cause the same problems as other operating systems.
4 Steps to secure your software supply chain
All is not lost with software supply chain attacks. These complex attacks can be mitigated. Below are some of the ways you can protect yourself:
Sort dependency confusion
Attackers can inject malicious packages via public sources into the software supply chain causing dependency confusion attacks. The otherwise called package name squatting attack consists of a few carefully planned steps:
The attacker identifies the names of private internal packages used in software builds. Next, they upload malicious packages with the same name as these private internal packages. When a developer tries to pull the private internal package, they pull the modified one alongside public packages. Then the malicious package gets pulled from the public upstream.
How can you protect yourself against this type of attack? Here are some pointers:
- Use scoped packages: This method locks the namespace for the package and ties it to a specific user or organization. This mitigates the chances of an attacker substituting the underlying package.
- Use repo-specific configuration: when you use an internal package repository, ensure you don’t proxy requests for private packages to the public registries. This paper by Microsoft explains ways to mitigate risk when using private package feeds.
Don’t allow install commands in open source packages
Some package managers by default will allow any installed package to execute arbitrary commands. Attackers can implant a backdoor allowing code injection. By adding a seemingly undetectable typo, it can deceive developers mistakenly installing a malicious package.
You can protect yourself by avoiding installing packages blindly or copying and pasting without confirming the package first. You can also add an ignore-scripts command line to the npm install command. This will help you prevent packages from automatically executing arbitrary commands.
Control sensitive information
Enabling tighter access control security measures such as multi factor authentication to prevent the exposure of sensitive information. Additionally, don’t store sensitive information in a repository and avoid publishing packages with sensitive information
Final thoughts
The Linux foundation recommends organizations to “harden their build environments against attacks”. This involves first, implementing some of the security practices described in this article. Proper security hygiene and basic common sense may go a long way, thus minimizing vulnerabilities that attackers can exploit.
