Malicious Packages Are a Rising Threat in Software Supply Chain Attacks

Welcome to the first post in the malicious software packages series for the DevOps and DevSecOps community. This technical series will focus on various malicious packages and their effects on the software supply chain.

We’ll dive deeper into malicious packages in each post, including 

• Defining software supply chain attacks and learning the critical role that malicious software packages play in them (you’re here)
• Analyzing real-world infection methods that attackers use to spread malicious software packages with examples from attacks discovered by the JFrog Security research team
• Understanding standard payloads used in malicious software packages and how attackers execute the payloads to serve their needs through various real-life scenarios
• Discussing how malicious packages can be avoided and detected, and which obfuscation techniques attackers use to hide malicious code

Here we go. Let’s discuss malicious software packages in your software supply chain.

• What’s a software supply chain attack, and what are the inherent security risks?
• Which type of threats exists in the software supply chain?
• Why would an attacker go for the software supply chain?

What’s a software supply chain attack, and what are the inherent security risks?

In a software supply chain attack, an adversary slips an intentional vulnerability, malicious code, or an entire malicious component into a trusted piece of software or hardware supplied and consumed in a hardware or software supply chain.

Modern software development involves integrating third-party software into enterprise applications. According to the 2021 Veracode State of Software Security report, 97% of a typical application written in Java is made up of open-source libraries. This statistic suggests that only 3% of Java’s code is original, showing just the depth and breadth of today’s third-party libraries and open-source code. 

This practice essentially builds a chain of trust between the parties in the software supply chain. But, in reality, this practice also requires risk because third-party software packages and open-source packages potentially contain vulnerabilities or malicious code delivered through the software supply chain, affecting all the applications that consume the vulnerable or malicious packages.

Which type of threats exists in the software supply chain?

There are three software supply chain security threats (diagram 1.1).

The first two threats show software vulnerabilities, intentional or unintentional. Those vulnerabilities usually refer to software bugs, where each bug is typically assigned a Common Vulnerabilities and Exposures (CVE) identifier when it’s disclosed and published.

The third software supply chain threat is the malicious component or software package. Unlike vulnerabilities that require exploitation, this threat includes actual malicious code that performs unwanted actions and malicious activity when used. A CVE is usually not assigned when the danger is disclosed for this type of threat. The entire package or specific versions of the package are removed from the package repository, for example, PyPi or NPM, after being reported as malicious. The lack of an identification mechanism for malicious package names and versions makes it very hard for developers and security stakeholders to track. We’ll discuss solutions to overcome this challenge in the following posts in this blog series.

Here are two real-world examples of these at play:

1. The Unintentional Bug: A great example is the infamous Log4Shell vulnerability that shook the world on December 2021. The Log4j package is highly used by Java projects and has affected many enterprise applications and cloud services like Apache Struts, Apache Solr, Apache Druid, and more.
2. The Intentional Bug: In 2020, an intentional bug injected a backdoor into the SolarWinds’ Orion software platform. The backdoor-laden version of the software was downloaded around 18,000 times and actively affected around 100 different companies.

If you’re wondering about real-life examples of malicious software packages, stick around because we’ll be taking a closer look at this particular threat in the “Malicious Software Packages” series in our next post the following week.

Attackers can utilize the above threats to perform actual attacks. The unintentional vulnerabilities of third-party code could also be considered a supply chain attack (like the widely exploited Log4Shell vulnerability that affected many enterprise organizations). Still, the conservative term of software supply chain attack usually refers to intentional sabotage of a supply chain by slipping a malicious code or planting an intentional vulnerability, as seen in the two examples above. So usually, while unintentional vulnerability is considered a threat to the software supply chain security, it’s out of scope when discussing attacking a supply chain.

Why would an attacker go for the software supply chain?

There are two reasons an attacker would go for the software supply chain. 

First, from a technical point of view, if you look at the essence of this methodology, you’ll see no specific targets involved in this type of attack. So, for example, when you attack a supply chain by infecting a single software package, you could strike all software that depends on this package and all the end consumers of applications that use this specific infected dependency. An attacker would go for the software supply chain approach because of the high distribution potential of the attack.

The second reason attackers exploit the software supply chain is the small effort they need to invest in a software supply chain attack compared to the classic targeted attacks that we’ve seen in the last 20 and 30 years when attackers focused on exploiting vulnerabilities. In a standard-targeted effort, attackers must invest ample time and money to compromise a single target. This attack becomes even more complicated when the target is a known software platform because it’s highly maintained and secured compared to the many relatively small software packages. 

An attacker would need high technical skills for a targeted attack because it essentially involves finding a vulnerability, developing a working exploit, or paying for one.

Look at the pricing table below from Zerodium; an exploit acquisition platform.

The above table shows that a remote code execution exploit can cost up to $1 million for a single exploit, with a zero-click RCE exploit for Windows being the most expensive. This table demonstrates the complexity and high bounty/rewards when exploiting vulnerabilities.

When comparing this effort to attacking a malicious open-source software package, the options are endless, as hundreds of thousands of packages are out there. Hence, the attacker simply has to find a single package to attack or publish a single malicious software package and abuse the trust between parties in the supply chain, making this attack method effective. In the next blog posts, we’ll see why and how easy it is to attack with malicious open-source packages.

Popular packages like faker & colors of NPM can be game over for a large consumer community who happen to be part of the supply chain of this package. As we published earlier this year, some packages can target the users of large enterprise solutions.

Stay tuned for the next part of the “Malicious Software Packages” blog series, where we’ll analyze real-world infection methods that attackers use to spread malicious software packages. In that post, we’ll provide examples from attacks discovered by the JFrog Security research team. And before you go, ask yourself this: How am I defending against software supply chain attacks and malicious packages? 

Want to learn more? Register for an upcoming JFrog webinar. 

This educational series has been adapted from the webinar Identifying and Avoiding Malicious Packages, a technical showcase of the different types of malicious packages prevalent today in the PyPI (Python) and npm (Node.js) package repositories.