Open-source software (OSS) fuels innovation. Over 96% of commercial applications rely on at least one OSS component (Synopsys, 2023).
At Cloudsmith, we champion OSS and understand its indispensable role in today's software landscape. However, the escalating threat of supply chain attacks targeting OSS demands a robust defence.
Step into our blog series on how to securely consume OSS. Over the next 3 articles, we'll guide you through
- The dangers lurking in OSS
- OpenSSF's Secure Supply Chain Consumption Framework (S2C2F) which outlines and defines how to securely consume OSS dependencies into the developer’s workflow.
- Implementing S2C2F with Cloudsmith
Today, I'll give an overview of some of the most common types of attacks from consuming OSS. These attacks can lead to broken builds, security breaches, unauthorized access, and data leaks.
Attackers are increasingly focusing on OSS, exploiting vulnerabilities to get malicious code into production systems. To achieve this, malicious actors employ three main avenues of attack when it comes to your OSS consumption:
- Public Repositories: Publishing bad packages to public indexes like PyPI, npm, or Maven Central.
- Maintainer-Based Attacks: accounts can be hijacked, projects abandoned, deleted or maintainers can introduce malicious code themselves.
- Vulnerabilities: Risks linked to vulnerabilities in your OSS dependencies, such as Log4Shell, Heartbleed and the recent high-severity vulnerability found in curl.
Public repository-based attacks
Languages with community-based package management, like npm for Javascript and PyPI for Python, make publishing and consuming packages easy. One downside to that is that hackers can publish malicious packages to these repositories to trick developers into installing the wrong package.
Unit 42’s 2023 threat report found 7,300 malicious OSS packages were discovered across all major package manager registries in 2022 alone.
Let’s have a look at these types of attacks.
Typosquatting
Typosquatting is when bad actors upload compromised packages with names similar to popular, existing packages. If a developer makes a typo when including a package name, the malicious but similarly named package is then downloaded and installed instead. This type of attack is tough to detect and can lead to malware execution.
An example of a typosquatting campaign unfolded in early 2023 when thousands of malicious Python packages were discovered on the public Python Package Index (PyPI). Similar campaigns have been observed in other popular package ecosystems, including:
- npm: The npm platform witnessed a typosquatting campaign leveraging open-source tools, emphasizing the widespread nature of this threat.
- NuGet/Powershell: The distribution of SeroXen RAT via a malicious NuGet package raised alarms within the NuGet and Powershell communities.
- Rust Crates: Evidence of a malware attack on Rust developers via typosquatting was identified on crates.io.
- Composer: Malicious typosquatting malware was uncovered within the Composer repository, underscoring the vulnerability of various ecosystems to such subversive tactics.
- Docker: A notable incident involving the exploitation of Kubernetes RBAC via a typosquatting attack on Docker served as a reminder of the far-reaching consequences of this practice.
The prevalence of typosquatting across multiple OSS ecosystems underscores the need for heightened awareness and vigilant measures within the developer and repository communities to effectively detect and mitigate this elusive threat.
Dependency Confusion
Security researcher Alex Birsan found he was able to get “malicious” code (actually just an innocuous test) into software built by more than 35 major companies (He had advance permission from each company to try.) These companies all were vulnerable to the injection of malicious packages via public sources into their software supply chains. His test demonstrated that the Dependency Confusion Attack can occur when attackers find out or guess package names in your organization's private repository and pull in the public package instead of the package hosted on the private repository.
A real dependency confusion attack was launched against PyTorch in late 2022. PyTorch had a dependency on a library called torchtriton that was hosted on PyTorch’s private repository. The attacker decided to register a malicous package on the public PyPI repository with the torchtriton name. When a build was triggered pip looked at the public PyPI first and pulled in the malicious package.
Maintainer-based threats
What would happen if a bad actor managed to hijack a Maintainer account? Or how about a malicious maintainer intentionally introducing bugs? Yes, sadly, both of those scenarios have happened.
These maintainer-based threats are more likely to happen in projects that have very few maintainers, which is actually the case for many packages in public repositories like npm and PyPI. Let’s look at a few examples.
Hijacked Maintainer Credentials
In 2021, crypto-mining, password-stealing malware was found in a popular npm package named ua-parser-js. "I believe someone was hijacking my npm account and published some compromised packages (0.7.29, 0.8.0, 1.0.0) which will probably install malware," said Faisal Salman, author of the UAParser.js library. He turned out to be right.
Another npm package, ESLint, had a similar attack in 2018. The attacker gained unauthorized access to the library and inserted code that could have potentially allowed for further malicious activities. These incidents highlighted the need for switching on 2FA for maintainers of popular packages.
A variation on this attack occurred in 2018 with a popular JavaScript library for Node.js called EventStream. The package was discovered to contain malicious code that enabled digital attackers to empty Bitcoin wallets. This attack happened when a malicious party used social engineering to be added as a maintainer. The attacker then added a dependency containing malicious code called flatmap-stream. Everyone who used event-stream with the malicious dependency became a potential target.
Good Maintainers Gone Rogue
Although very rare, it is not unheard of for legitimate maintainers to intentionally introduce bugs or delete code in an update for political or other reasons.
In 2022, the popular npm package node-ipc was sabotaged by its maintainer, Brandon Novaki Miller, to protest the ongoing war in Ukraine. He released an update to npm and GitHub that sent peace messages to all users and deleted files belonging to users based in Russia and Belarus.
In a similar self-attack in 2022, colors and faker npm packages were corrupted by their Maintainer, Mark Squires. He intentionally introduced an infinite loop that broke thousands of projects that depend on colors and faker to protest Fortune 500 companies using OSS for free, as well as to highlight his political interests. Mark was locked out of his GitHub accounts, but eventually, he took down his popular faker package altogether.
Another incident of this type occurred in 2016 on npm when Azer Koçulu removed over 250 of his modules from npm after a disagreement. One of those dependencies was a popular package called left-pad. Laurie Voss, CTO and co-founder of npm, took the unprecedented step of restoring the unpublished left-pad 0.0.3 package.
Abandoned OSS
OSS projects get abandoned all the time. The original maintainer may move on or lose interest, and nobody else steps in. These abandoned projects pose a security risk as vulnerabilities go unpatched.
Known vulnerabilities in OSS
Vulnerabilities in OSS represent an enduring and significant threat. Known vulnerabilities are publicly disclosed weaknesses cataloged in databases like the National Vulnerability Database (NVD), and are susceptible to exploitation by attackers.
These vulnerabilities can range in severity, with critical ones often enabling Remote Code Execution (RCE) that grants unauthorized control over systems.
At first glance, it might seem easy- if you have an OSS dependency with a known vulnerability in your software, just update it to make the issue go away. But in reality, this can be tricky because:
- There's no consistency with how developers are bringing in OSS which leads to security tool blind spots.
- You might not be aware that you're using a vulnerable package, particularly when that package is a dependency of another package— commonly known as a transient dependency.
- The vulnerable package is a dependency in legacy software that isn’t receiving updates.
- The dependency is abandoned OSS. In such cases, nobody is around to fix those vulnerabilities and/or update vulnerable dependencies.
In a nutshell, fixing vulnerabilities in your software isn't always as simple as it sounds, especially when you bring in OSS in different ways, they're buried deep in your software, tied to older programs, or linked to abandoned parts that nobody's looking after.
Let’s take a closer look at the infamous vulnerability Log4Shell to illustrate the threat of vulnerabilities in the OSS you consume.
Log4Shell
In February 2022, Log4Shell was discovered within the widely-used OSS logging tool Log4J, leaving its users and their organizations susceptible to remote code execution attacks.
Log4Shell had an extraordinarily broad and damaging impact:
- It had a huge attack surface, including Cloudflare, iCloud, Minecraft servers, Steam, Tencent QQ, and millions more.
- It was easy to exploit.
- It had a Common Vulnerability Scoring System (CVSS) score of 10 (the highest, or worst, possible score) - a successful exploit left organizations wide open to remote code execution attacks.
- It was hard to detect because it was typically pulled in as a dependency of a dependency.
Rezilion researchers found that several customers who had completely mitigated Log4Shell from their environments saw it reenter their systems through a continuous integration (CI) process or the installation of a vulnerable third-party application.
Secure Supply Chain Consumption Framework
Attacks targeting OSS are on the rise because they work, and because so many software organizations aren’t taking adequate precautions.
OpenSSF, the Open Source Security Foundation, unites OSS maintainers, industry leaders, governments, OSS consumers, and more to enhance OSS security for all.
Their Secure Supply Chain Consumption Framework (S2C2F) provides essential guidelines and best practices to bolster security when consuming OSS.
In our next blog, in our series on how to securely consume OSS, we'll delve into the S2C2 Framework, exploring how it can significantly mitigate the risk of OSS attacks.
