We use cookies to enhance your experience of our website, save your preferences and provide us with information on how you use our website. For more information please read our Privacy Policy. By using our website without changing your browser settings you consent to our use of cookies.
Oct. 1, 2023 Defend Against Dependency Confusion Attacks
7 minutes read
Defend Against Dependency Confusion Attacks

Software libraries play a crucial role in software development in that they assist in building and executing software. Most programming languages have their own package manager. This element makes it easy for users, as they only need to specify the library name or source and version, and the package manager takes care of the download and installation. Software engineers can, therefore, quickly develop complex applications without reinventing the wheel. Unfortunately, while package managers simplify the development process, they have also introduced new vulnerabilities, such as dependency confusion attacks.

Dependency confusion tricks the package manager into installing an arbitrary package. This deceit can undermine the security of the software and allow adversaries to access sensitive information or backdoor the application. Therefore, developers and software architects need to be aware of dependency confusion.

Can dependency confusion impact you?

Alex Birsan first revealed dependency confusion as a novel supply chain attack in 2021 after successfully hacking into Apple, Microsoft, PayPal, Tesla, Uber, and more than 30 other major companies. The way he was able to successfully penetrate these companies is detailed in the next section. Then again in December 2022 during the holiday season, a targeted dependency confusion attack was disclosed by PyTorch. Particularly, users of their PyTorch-nightly build that downloaded its dependent packages from a private Python registry. The dependency targeted in the nightly build was a package called torchtriton. The official PyPI package index that releases official versions was not affected.

If your organization maintains internal source code libraries, the threat of dependency confusion attacks can be significant unless adequate protection is in place. Packages hosted on private registries can have the same name as public ones. Unless the package manager is configured to look up private registries first, it may automatically use public packages containing arbitrary code. As more software applications rely on open-source packages and third-party dependencies, the risks will continue to rise.

How dependency confusion works

In dependency confusion attacks, an external adversary tricks the package manager into downloading a malicious third-party package instead of the intended private package developed by a private entity. The anatomy of a dependency confusion attack includes the following steps:

  1. An adversary uploads a malicious software package to a public repository - e.g., another-package with a high version number like 99.99.

  2. An organization maintains a local repository with self-developed or adjusted software libraries that hosts a package with the same name as another-package in a lower version like 1.2.

  3. A software engineer of the organization aims to utilize a library with the name of another-package from the organization’s local repository. However, the software engineer neglects to specify additional crucial information, including the package’s version number and origin.

  4. When installing the package, the package manager will automatically take the version from the public repository with a higher version number considered the latest version.

The package manager should first look for the private package and then seek the public one. Instead, it searches both repositories and automatically takes the package with a higher version number. This process allows an adversary to create malicious packages with names hosted in private company repositories. In the case of PyTorch, the attackers went on the official repository of Python's programming language, Python Package Index (PyPI).

If an organization is unaware of the situation, the package manager may automatically include that public library and the adversary can backdoor the entire application. This backdoor could give the adversary access to sensitive data or system resources or carry out further attacks like data exfiltration, malware distribution, and ransomware. This attack applies to most package managers, such as npm, Pip, RubyGems, Maven, etc.

Protection against dependency confusion attacks

There is no single solution to mitigate supply chain attacks or all potential substitution threats across all programming languages and their package managers. However, the following best practices can help minimize the risks:

  1. Verify dependencies: Verify the authenticity of all dependencies before using them, for example, by using secure checksums or digital signatures. This is because verification allows developers to ensure that their dependencies are intended and have not been tampered with or replaced with malicious versions. In addition, by confirming the authenticity of each dependency, malicious packages from public repositories will be rejected if private packages are intended to be used.

  2. Use internal package registries: Use internal package registries separate from public package repositories. This distinction helps minimize the risk of having packages with the same name as public repositories. Internal package registries help avoid conflicts that might arise from having packages with the same names as those on public repositories and provide greater control and security over the packages used in the software development process.

  3. Use versioning and namespacing: Use versioning and namespacing in your dependencies to prevent attackers from creating packages with the same names. By versioning dependencies, developers can ensure they use the correct package version and avoid unintentionally installing an alleged newer version. On the other hand, namespacing allows developers to differentiate packages with similar names, making it harder for attackers to create packages with the same names as legitimate ones.

  4. Safelist dependencies: Create a safelist of approved dependencies and only allow installations from that list - this practice is also vital if you‘re not maintaining internal repositories. By restricting installations from a pre-approved list, developers can ensure that only trusted dependencies are used in their software development process. This pre-qualification can help prevent the unintentional installation of harmful third-party dependencies and reduce the risk of a supply chain attack.

  5. Monitor package usage: Regularly monitor the usage of packages in your systems to detect any unauthorized or malicious packages. Monitoring the packages will help developers identify instances where unauthorized or malicious packages may have been installed. This exercise can help prevent the use of such packages, limiting the potential damage they may cause.

  6. Educate your team: Educate your software engineers and architects on the risks of dependency confusion attacks and the importance of verifying the authenticity of dependencies before using them. This is because by being aware of the dangers, developers can take appropriate measures to ensure that only trusted dependencies are used in the software development process. Educating developers can also help them recognize suspicious package behavior or detect any signs of a supply chain attack. 

Remember that there is no one solution to prevent all types of dependency confusion attacks, so implementing multiple layers of security is highly recommended.

About the Author

Saad Ahmed is a Security Engineer at Certus Cybersecurity. A specialist in network, web, and mobile application penetration testing, Saad is also an experienced Red Teamer and bug bounty hunter.

Contact Us
Ready to get started? Book a free consultation today, and we’ll write you back within 24 hours. For further inquiries, please submit the form at right. By submitting completed “Book a Free Consultation” form, your personal data will be processed by Certus Cybersecurity. Please read our Privacy Notice for more information.