The Open-Source Package Poisoning Attack Vector

The Software Supply Chain Risk 

The software supply chain has quickly risen to become one of the largest security obstacles for companies to tackle. The challenge is clear; the modern software development process is composed of an ever-growing amount of interconnected parts. We’re talking about multiple tools, steps, plugins and packages, as well as different languages, frameworks, and connectivity methods. Although this is what inherently enables companies to develop their software in the most agile and fast way, it has also resulted in the creation of one of the most dangerous cyber-attack vectors of the past decade; software supply chain attacks. 

One of the major dangers of this vector is that it’s not just a single point that needs to be protected; rather, it is a collection of multiple small entry points. For attackers, all it takes is identifying the weakest of these multiple entry points, breaching it, and then using it to trigger long-lasting damage across the software’s supply chain. This is a much more dangerous concept than that of lateral movement; the victim is no longer the breached company, but all of the users of its software.

So let’s dive deeper into some of these entry points…

Modern software development pipelines consist of various steps within the continuous integration and continuous delivery (CI/CD) process. Typically, multiple tools and services are used at each of these steps to run the process, introducing an added layer of risk. 

There are many ways to divide the (sub) attack vectors, but for the purpose of this blog I’ll divide it into internal and external risks. 

• Internal – These refer to security risks stemming from weak company policy, misconfigurations, and vulnerabilities within the company’s software development infrastructure and environments. 
  • Some examples of this are lack of multi-factor authentication enforcement, excessive user privileges, and hard-coding secrets into source code

• External – These refer to security risks stemming from targeted attacks which use external components and dependencies which are part of the pipeline, such as images, packages, and plugins, to poison the development process. Vulnerabilities and risks that are part of these external components are harder to track and thus, easy to pull into the internal process. 
  • Some examples of this are malicious plugins and services connected to the pipeline (such as when the Codecov plugin was compromised to start printing sensitive data and secrets), vulnerable images being pulled from unsecured registries, dependency confusion cases in which malicious packages are pulled instead of legitimate ones, and open-source package poisoning attacks. 

In this article I will focus on one of the fastest growing attack vectors – Open source package poisoning

Open-source packages are like a gold-mine for attackers – They are by default open and highly popular, meaning typically easier to penetrate and an opportunity to reach massive amounts of users. 

So this is how it usually works: Attackers gain access to or ownership of an open-source package or library. They tamper with it, usually injecting malicious code inside it. It then gets merged, updated, and downloaded by thousands if not millions of users who are looking to use and get the benefits of the original open-source package. This is how attackers essentially poison the well; they poison the open-source package and get developers to unintentionally contaminate the software they’re developing, usually opening backdoors that the attackers can later access or use to get sensitive data. 

The challenge is not hard to understand; there are hundreds of thousands of open-source packages with an even larger number of contributors. It’s easy to lose track and visibility over the packages you’re using and the security level of each one. This leads software development teams to unknowingly pull malicious versions of the OS package they want into their development. Just to add to this risk, there are many vulnerabilities and misconfigurations discovered within these packages on a weekly basis that attackers can take advantage of as a way to trigger attacks, even if the package initially pulled in was “secure”. 

We don’t need to look far; in the span of a week, three major supply-chain attacks were triggered from this vector. 

The case of COA – COA stands for command-option-argument, and its an open-source library that averages ~9M downloads a week on NPM. It’s estimated to be used by 5M open-source repositories on Github and its used in React packages all over the world. Before this week, the last version (2.0.2) had been released 3 years ago. Suddenly, this week several new versions appeared on NPM. That was the first warning sign.

10 minutes after, a thread was opened by Roberto Overdijk about the fact that these new versions had broken his build. Soon after, many developers joined the discussion and confirmed the issue. 

Following the community investigation, it was discovered that the new versions contained a suspicious preinstall script which we now know launched a malicious javascript file. It seems like the malware in question is Danabot, a password-stealing Trojan for Windows. When downloaded, it can perform malicious activities such as steal passwords from web browsers and applications, steal stored credit cards, and take screenshots of active screens. 

“preinstall”: “start /B node compile.js & node compile.js”

Soon after discovering the breach, developers spotted that another popular open-source component, RC, had also been affected. This is an even more popular library than coa, with ~14M downloads a week. 

Unsurprisingly, both of these attacks have been linked to the large scale supply chain attack on ua-parser-js that was discovered last week. The malware found in the three attacks is virtually identical, establishing a likely link between the threat actors behind the separate incidents. 

So what are the main points to take from the coa supply chain breach?

• Easy access, large impact – The attackers were able to tamper with the package by gaining access to the account of one of the developers of the package (yes, we’re essentially talking about a single password), and from there cause impact to millions of downloads. 
• In this case it didn’t; but it could have easily gone undetected – If the attack hadn’t been built only for Windows, other builds wouldn’t have failed and it probably would have taken most companies a long time to detect the issue.This means that millions could have been exposing and leaking sensitive company information for a prolonged period of time. 

So here are the 5 steps you need to take to protect your software supply chain from incoming poisoned packages:

1. Have visibility over all existing and new external pipeline dependencies
2. Establish protocol of review and approval for new, unverified dependencies
3. Scan all packages for both known and unknown vulnerabilities
4. Scan and alert on any abnormal behavior and compromises. 
5. Establish and enforce company policy on package usage.

As mentioned at the beginning of the article, this is just one of the attack vectors within the software supply chain that security and devops leaders need to worry about. We know the security risks can be overwhelming and it’s not always easy to allocate resources and budget to deal with this complexity. 

Argon can provide you with an effective security solution that fits your Dev pipeline, enabling you to prevent these attacks by:

1. Gain full visibility – Argon scans all your tools, repositories and projects, and provides you visibility and insights across your environment, including any and all dependencies which form part of your pipeline.
2. Orchestrate security scans – Make sure that all of the code scans which are important to you are running according to policy, and that all open-source vulnerabilities are being scanned and alerted about in real-time. 
3. Build and enforce security gates – Define the rules that you want your process to meet and identify and prevent zero-day attacks by analyzing the behavior of the package before they move downstream through the development steps. For example, stopping the ua-parser-js attack by identifying changes in ownership and risky age of the package.

To learn how Argon can help you close this and the rest of the attack vectors within the software supply chain, reach out to info@argon.io