Supply chain attacks – Threats and protection mechanisms (part 1)

• By using frameworks and libraries, developers can concentrate on the essentials – the added business value – instead of reinventing the wheel for the umpteenth time in certain areas.
• The use of managed services, e.g. for single sign-on (SSO) or Active Directory services, makes it possible to integrate existing third-party functionality into your own application, in order to focus on added business value as well.
• It has become the de facto standard for development teams to use container images to deliver their applications in a containerized manner; the container images are usually based on images created by other companies, organizations or individuals.

This list is incomplete when it comes to components targeted by supply chain attacks! However, it should serve as a reference point for attack vectors, actual supply chain attacks and protective measures.

A study by Juniper Research [01] shows that supply chain attacks are both highly dynamic and highly significant and will become increasingly important: While the estimated global damage caused by supply chain attacks in 2023 was around USD 45 billion, the authors of the study expect this damage to amount to USD 81 billion by 2026 – with an upward trend in the years after 2026.

It is therefore essential for companies and organizations to be aware of the threats posed by supply chain attacks and to know how to protect themselves effectively against them!

The integration of frameworks and libraries – summarized in this section as dependencies – is an integral part of today’s software development. The reasons for this include considerable efficiency gains, as outlined in the introduction.

In the following, we look at the attack vectors that dependencies offer for supply chain attacks, the damage they can cause and how you can protect yourself against these attacks.

Attack vectors

Due to the importance of dependencies, attackers regularly and deliberately try to inject malicious dependencies into software projects. Attackers use the following methods, among others, to achieve this:

Option 1: Attackers create a malicious package based on another widely used benign package, giving the malicious package a confusingly similar name. The assignment of such names is known as typosquatting.

The company Phylum, for example, uncovered an attack campaign in October 2024 in which the benign npm package (1) called “puppeteer”, which records millions of downloads per week [02], was selected for such a typosquatting attack. The attackers published malicious npm packages under the names “pupeter” and “pupetier” [03].

The npm packages “pupeter” and “pupetier” were removed from the npm registry after the campaign was uncovered; this is one of the reasons why these two packages were only downloaded about a dozen times in total.

Option 2: Attackers create a malicious package and specifically try to get developers from a selected group to include it.

Phylum uncovered such a campaign in August 2023 [04]. As part of this campaign, which Phylum describes as “sophisticated”, the packages “ynf-core-loader” and “ynf-dx-webpack-plugins”, among others, were uploaded to the npm registry (2). Since these packages were not named using typosquatting, Phylum assumes a targeted campaign, presumably combined with social engineering, to install the package on specific individuals’ computers. If this assumption is correct, this means that the attackers had contact with the victims in order to convince them to integrate the malicious packages.

Possible damage

Attackers usually use so-called install hooks to execute the malicious code for which the packages were created during package installation. This malicious code can, for example, be a backdoor – a mechanism by means of which the attackers create permanent access to the infiltrated developer computer that is not obvious to the victims.

From the affected developer computer, the attackers now have various options, including:

• Attackers can tap into source code – e.g. to gain a competitive advantage or to specifically examine source code for vulnerabilities and thus compromise productive systems.
• The attackers can use the developer system to gain access to other internal company or organizational systems.

If malicious packages are discovered too late, they also infiltrate other developer computers or even CI/CD (continuous integration/continuous delivery) systems over time.

Such an attack necessitates a comprehensive analysis, especially with regard to the systems that the attackers have accessed or still have access to. As a rule, a complete clean-up/reinstallation of the affected systems is necessary. This is an immense damage, caused by nothing more than the inclusion of a dependency in a software project!

Developers themselves represent the first and most important line of defense against this attack vector. In this respect, it is obvious that protective measures affect developers. Two protective measures are listed below; this list should be regarded as incomplete.

Protective measure 1: Do we really need a new dependency?
First, the development team should clarify whether a required functionality really requires the integration of a new package.
There are now packages for many small functions, such as checking a character string to see whether it represents a number [05]. Particularly with regard to security, development teams should carefully consider whether they really want to include a package as a dependency.
It is perfectly justifiable to develop a functionality for which there is already a package, but which has a limited scope so that you can justify developing and maintaining this functionality yourself.

Protective measure 2: Check packages!
Before integrating a new package, the package should be examined more closely by developers. The answers to the following questions help to assess whether a package could be malicious:
1.    How long has this package been available?
2.    How many downloads/stars/forks does this package have?
3.    Is the source code for this package publicly available and permanently linked to a specific version in the package registry?
4.    What open issues and comments are there on this package?

However, the answers to these questions do not provide 100% certainty. For example, this was demonstrated by the addition of a backdoor to the widely used xz library [06].
As described above, supply chain attacks can be combined with social engineering, making them even more dangerous. Protection against social engineering is a separate field about which entire books have been written [07], so we will not go into it further here.
 

SBOM stands for “software bill of materials”. Among other things, an SBOM lists all integrated dependencies, including their versions and transitive dependencies. This information can now be used to check the dependencies against lists of known vulnerabilities to see if there are any threats.

However, SBOMs do not provide any protection against malicious packages! For a package to appear as a dependency in an SBOM, it must first be added to the dependencies of a software. However, as described above, many malicious packages execute their malicious code during installation.

SBOMs can only detect that a malicious package has been included and therefore do not provide any direct protection.

Summary

This blog post has introduced supply chain attacks, roughly presented some of the many supply chain attack vectors and examined the “frameworks and libraries” attack vector in detail.

In a second blog post, we will look at further attack vectors, their effects and protective measures.

References
(1) npm stands for Node Package Manager and is a package manager in the JavaScript/TypeScript ecosystem.
(2) The npm registry is a frequent target due to its widespread use. Other package registries can theoretically be and are practically also misused for these attacks.
[01]​ https://www.juniperresearch.com/press/study-reveals-staggering-cost-of-software-supply/
[02] ​https://www.npmjs.com/package/puppeteer
[03]​ https://blog.phylum.io/supply-chain-security-typosquat-campaign-targeting-puppeteer-users/
[04] ​https://blog.phylum.io/sophisticated-highly-targeted-attacks-continue-to-plague-npm/
[05] ​https://www.npmjs.com/package/is-number
[06]​ https://www.heise.de/hintergrund/Die-xz-Hintertuer-das-verborgene-Oster-Drama-der-IT-9673038.html
[07]​ https://www.mitp.de/Unsere-Autoren/Kevin-D-Mitnick/Die-Kunst-der-Taeuschung.html