In recent years, supply chain attacks targeting software developers and suppliers have become increasingly common. The primary objective of these attacks is to gain unauthorized access to source codes, build processes, or update mechanisms by infecting legitimate apps with malware. Then, by abusing the vendor-customer trust relationship, they can quickly infect a large number of organizations that unknowingly install the infected package. In the case of home-grown applications, the organization’s users and suppliers can be affected. Given the potential gains, it’s no wonder that supply chains are an attractive target for malicious actors.

One way attackers can carry out a supply chain attack is by exploiting ‘Dependency Confusion.’ In these types of attacks, malicious actors try to exploit the common practice of using third-party software libraries and utilizing package managers to automatically download and install the necessary packages for their applications. Although this is not a new type of attack, at Orca we were surprised to find that nearly half of organizations are vulnerable to this type of attack.

This is especially concerning since the impact of supply chain attacks can be enormous, and are devastating to organizations, suppliers, and customers. In this blog, we explain how a Dependency Confusion attack can take place and what measures can be implemented to minimize this risk.

Executive Summary

  • Based on research from the Orca Cloud Security Platform, nearly half of organizations are vulnerable to a Dependency Confusion attack (49%). 
  • A Dependency Confusion attack is a type of supply chain attack where an attacker publishes a malicious package to a public package repository with the same name as a popular package. This causes the package manager to unknowingly download the malicious package from the public repository instead of the intended private repository.
  • Attackers can take an opportunistic approach, where they upload several malicious packages with the same name as popular package dependencies, or they can initiate a targeted attack where they know which file names are being used in specific libraries.
  • If successful, a Dependency Confusion attack can have disastrous consequences, infecting all the vendor’s customers that install the malicious package. These organizations could then be targeted with unauthorized access, data theft, ransomware, and more. Some examples of Dependency Confusion attacks are PyTorch and node-ipc.
  • Dependency confusion risk can be mitigated by ensuring that developers review and verify their packages and keep their dependencies up to date. In addition, the Orca Cloud Security Platform has added new capabilities to alert organizations to any vulnerable packages so they can ensure that they link to the private repository instead.

Orca alerts to an NPM dependency package that isn’t listed on the public registry

What is a Dependency Confusion Attack?

A Dependency Confusion attack is a type of attack that exploits the way modern development environments and package managers work, such as Node Package Manager (NPM) and Python Package Index (PyPI). Developers commonly use third-party software libraries in their projects, and rather than including the library in the package, they include links to the original library to be downloaded from a private repository. However, by default, package managers first look for the library on public repositories. If a package with exactly the same name exists on a public repository, that package will be downloaded instead of the legitimate package on the private repository. This can introduce malicious code into the application, potentially compromising the security of the entire organization and if applicable, their customers.

Workflow of a Dependency Confusion attack

One example of a Dependency Confusion attack on PyPI is the late December 2022 attack on PyTorch, where an attacker uploaded a malicious ‘torchtriton’ dependency on PyPI that shared the same name as the one on the official PyTorch library. Since PyPI normally takes precedence when fetching dependencies in the Python ecosystem, the malicious package was pulled during installation, instead of PyTorch’s legitimate one.

Another example from spring 2022 is a Dependency Confusion attack where certain versions of the massively popular ‘node-ipc’ package contained malicious code that would overwrite or delete arbitrary files on a system for users based in Russia and Belarus. 

A Surprisingly Common Problem

By analyzing NPM and PyPI packages stored in cloud environments scanned by the Orca Platform, we found that as many as 49% of organizations have at least one vulnerable asset, and over 28% have 50 assets or more that are potentially vulnerable to a Dependency Confusion attack.

Dependency Confusion is a surprisingly common issue

Packages considered vulnerable include a dependency to a software library that doesn’t exist on a public repository, meaning that a malicious actor could upload a library to a public repository with the same name, ‘tricking’ the package manager to download that library instead, since this is how package managers are configured by default.

Public Versus Private Registries

A public registry is a repository of packages that is openly accessible to everyone, including developers, organizations, and attackers. Examples of public package registries include NPM and PyPI. A private registry, on the other hand, is a repository of packages that is only accessible to authorized users and organizations. Private registries are typically used by organizations to store and manage packages that are specific to their needs and are not intended for public use. Access to private registries is usually restricted through authentication and authorization mechanisms.

In terms of supply chain attacks, public registries are more vulnerable to these types of attacks due to their open nature. Attackers can inject malicious packages into the registry, which can then be unknowingly used by developers in their projects. This can lead to security incidents such as data theft, unauthorized access, or other types of attacks.

Private registries, while less accessible to attackers, are not immune to supply chain attacks either. Attackers may be able to gain access to private packages through other means, such as exploiting vulnerabilities in the registry or compromising the credentials of authorized users.

For example, in the case of NPM packages, an attacker can create a malicious package with the same name as a legitimate package and upload it to npmjs.com, the official package repository for npm. When a developer specifies a dependency on the legitimate package in their package.json file and runs npm install, the package manager will install the attacker’s package instead of the legitimate one, leading to a successful Dependency Confusion attack. The malicious package can then exfiltrate sensitive information or execute arbitrary code on the developer’s machine.

POC of a Dependency Confusion Attack

Below we discuss a proof of concept of how a Dependency Confusion attack can be achieved:

Let’s take the example of Organization X that uses a number of NPM packages for their internal CI/CD process, including some well-known NPM packages. In addition to those, there is a package named production-x-company-internal1, which, as its name suggests, is an internal package that is not registered in the npm public registry.

The Dependency Confusion technique described by Alex Birsan can be exploited by malicious individuals to gain access to confidential information about a company’s cloud infrastructure. This attack relies on specific weaknesses in the organization’s NPM CI/CD process, including the use of packages from the public registry. In addition, the attacker must possess knowledge about internal packages that are not available in the public registry. By creating and uploading a malicious package with the same name as one of these internal packages, the attacker can trick the CI/CD process into fetching the malicious package instead. This allows them to execute the supply chain attack and potentially retrieve sensitive data.

The attacker creates a package containing a malicious payload, which is stored in the index.js file. The attacker’s objective is to steal sensitive information related to the AWS cloud provider, including the config and credentials files and data from the AWS IMDSv2 service

“http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance/” to retrieve the confidential IMDS data.

In addition to the main variables, the attacker also attempts to obtain other information, such as the hostname, username, and UID of the host.

The final payload, as well as the four custom headers that will be sent to a remote Burp Collaborator, are shown in the screenshot above.

The final step for the attacker is to publish the package so it will become public, and then wait for the victim to install our malicious package.

We can see from the screenshot above that the attacker was able to successfully send a POST request back to our Burp Collaborator, with the sensitive data extracted from the vulnerable host. The custom headers were filled with the information that was obtained, as shown in the screenshot.

You can find various examples of Postware in our blog on open source package risks, where we discuss the various scenarios that led to the attack, the technical details on how such an attack can take place, and a walkthrough of how such an attack can be launched by a bad actor.

How Can You Minimize Dependency Confusion Exposure?

Below we list best practices that can be followed to mitigate the risk of Dependency Confusion attacks in NPM and PIP. It’s important to note that no single mitigation strategy is foolproof, and organizations should implement a combination of these strategies to reduce the risk of a successful attack.

  1. Package name verification: Ensure that the names of all packages being used in your project are known and trusted. This can be done by verifying the source and maintainer of each package before adding it to your dependencies. Additionally, you can use tools like npm’s npm audit command or pip’s pip check command to detect any vulnerabilities or inconsistencies in your dependencies.
  2. Package signing: Utilize package signing to verify the authenticity of packages. For example, npm has a package signing feature that allows maintainers to sign their packages and provide a cryptographic guarantee that the package has not been modified.
  3. Use private package registries: Consider using private package registries to host your internal dependencies. This can help to reduce the risk of attackers introducing malicious packages with similar names to your dependencies.
  4. Automated security scans: Implement automated security scans that regularly check your dependencies for vulnerabilities and other security issues. This can help to catch any malicious packages before they are able to cause harm.
  5. Code review: Conduct regular code reviews to ensure that the code being executed in your system is known and trusted. This can help to catch any malicious code that may have been introduced through a Dependency Confusion attack.
  6. Monitor package downloads: Monitor downloads of your packages to detect any unusual activity. This can help to identify a potential Dependency Confusion attack early on and take appropriate action.
  7. Regularly update dependencies: Regularly update your dependencies to ensure that any security vulnerabilities are addressed in a timely manner. This can help to reduce the risk of attackers exploiting known vulnerabilities in your dependencies.
  8. Detect vulnerable packages: By using a platform such as Orca (see paragraph below), you can be alerted to any packages that include a dependency to a software library that doesn’t exist on a public repository, and are thus vulnerable to exploitation by a malicious actor who could upload a library to a public repository with the same name.

How Orca Helps Mitigate This Risk

In view of the scale of the Dependency Confusion supply chain attack exposure, Orca has introduced new capabilities to alert organizations to vulnerable packages.

Leveraging our SideScanning technology, the Orca Platform is able to detect and parse dependency definitions in common files such as Python’s requirements.txt and NPM’s package.json, and extract a list of dependencies. The list is then compared against the public registries of PyPI and NPM, and the platform alerts to any packages which are not registered there.

Orca alerts to a PyPi dependency package that isn’t listed on the public registry

If Orca finds vulnerable packages in npm (Node.js package manager) or pip (Python package manager), the issue can be remediated as follows:

  • Rename your vulnerable packages: Use unique package names to minimize the chances of a duplicate package name being uploaded to a public repository. For example for the alert above, rename the package ‘generaldelta’ to ‘xyz##generaldelta.’
  • Secure your package repositories: Set up a private package repository or registry, such as an npm registry, to limit package installations to authorized sources and reduce the risk of fetching malicious packages from public repositories. For example, by configuring the .npmrc file in your project, npm will prioritize the internal registry, ensuring a secure software supply chain. This practice safeguards against potential vulnerabilities and maintains control over the packages used in your projects.
  • Set up authentication of package sources: Verify the authenticity and integrity of packages by implementing package signing and verification mechanisms. This ensures that packages are sourced from trusted publishers and have not been tampered with during transmission.

In addition to these remediations, following the best practices referenced in the previous section will help further reduce an organization’s exposure to Dependency Confusion attacks.

About the Orca Cloud Security Platform

The Orca Cloud Security Platform identifies, prioritizes, and remediates risks and compliance issues across your cloud estate spanning AWS, Azure, Google Cloud, Alibaba Cloud, and Kubernetes. Leveraging its patented SideScanning technology, Orca offers comprehensive cloud security coverage detecting vulnerabilities, misconfigurations, lateral movement, API risks, sensitive data at risk, anomalous events and behaviors, and overly permissive identities. Instead of layering multiple siloed tools together or deploying cumbersome agents, Orca delivers complete cloud security in a single platform.

Learn More About Orca Security

Would you like to learn more about the Orca platform and how it can prevent Dependency Confusion attacks? Sign up to view a 10-minute recorded demo, or schedule a 1:1 demo with one of our experts. Alternatively, sign up for a free risk assessment and find all Dependency Confusion risks in your packages.