Dependency Confusion Attacks
In recent years, there has been a significant increase in the number of software supply chain attacks. These attacks target the various components that make up a software application, such as libraries and frameworks, to infiltrate and compromise the software. One type of attack that has gained attention in this space is dependency confusion. In this blog, we will take a closer look at what dependency confusion attacks are, how they work, and what steps can be taken to mitigate them. Dependency confusion attacks, also known as substitution attacks, are a growing concern for software developers and companies that rely on open-source packages. These attacks exploit the way that software dependencies are managed in modern development environments, and they can have serious consequences for the security and integrity of software systems.
What is Dependency Confusion?
Dependency confusion targets the way developers manage dependencies in their software projects. Dependencies are external libraries or frameworks that a software application relies on to function. Developers often use package managers, such as npm or pip, to manage these dependencies and automatically download and install the necessary packages. The attack works by injecting a malicious package into a public package repository, such as PyPI or npm, that has the same name as a package that a developer is already using in their project. The developer, not suspecting anything malicious, will automatically download and install the package. The malicious package, in turn, will execute malicious code on the developer’s system, giving the attacker control of the developer’s environment.
PyTorch Dependency Confusion Attack
Users who deployed nightly builds of PyTorch between Christmas and New Year received a malicious package as part of the installation. PyTorch is a machine learning framework used for applications such as computer vision and natural language processing, originally developed by Meta AI and now part of the Linux Foundation umbrella.
A malicious library with the same name as the PyTorch framework torchtriton library appeared on the Python Package Index (PyPI), masquerading as the original torchtriton library but containing info stealer code that siphons sensitive information from infected systems. The stolen information included the IP address of the infected host, the username, the current working directory, environment variables, contents of /etc/passwd, $HOME/.ssh, and $HOME/.gitconfig, as well as the contents of the first 1,000 files in the HOME directory.
The malicious library uploaded all information to the h4ck[.]cfd domain via encrypted DNS queries to evade detection. When browsing to the h4ck[.]cfd domain, a notice from the author explains how the whole operation is part of ethical research. However, the analysis strongly indicates otherwise, and the breadth of the collected information is too broad to believe that it was only obtained to help the white hat identify the breached organization.
Figure 1: h4ck[.]cfd notice
The Increasing Use of Open Source
A key factor that makes dependency confusion attacks, and software supply chain attacks in general, possible is the increasing use of open-source packages in software development. Many software developers rely on open-source packages to provide functionality that they don’t have the time or resources to implement themselves. This makes it easy for attackers to find and exploit popular packages that are widely used in the software development community.
Once an attacker has successfully uploaded a malicious package to a public package repository, they can then wait for developers to start using it in their projects. Depending on the popularity of the package, this could happen very quickly, and the attacker can then use this to steal sensitive information, install malware, or take over the developer’s system.
One of the challenges of defending against dependency confusion attacks is that they are difficult to detect. In many cases, the malicious packages copy the functionality of the legitimate packages with some additional, malicious functionality added to it. Developers may not notice any difference when they are using them. Additionally, many package managers don’t have the ability to verify the authenticity of packages, and so developers may not be aware that they are using a malicious package source from a different location than the original author intended.
Mitigating Dependency Confusion Attacks
One way to mitigate the risk of dependency confusion attacks is to use package managers that have built-in security features. For example, some package managers, such as npm, have implemented digital signature verification to ensure that packages are authentic and have not been tampered with. Developers should also be careful to only use packages from trusted sources and to review the code of any packages that they use to look for any suspicious or malicious intent.
Alternatively, organizations could use a private package repository. By using a private package repository, developers can control who can upload packages and can ensure that only trusted individuals upload verified packages.
Another important step in defending against dependency confusion attacks is to keep software development environments up to date. This includes making sure that all packages and dependencies are up to date, and that any known vulnerabilities in these packages are patched. Additionally, organizations should have a plan in place to quickly respond to any security incidents that occur, and to take steps to limit the damage caused by any successful attacks.
In conclusion, dependency confusion attacks are a growing concern for software developers and organizations that rely on open-source packages. These attacks exploit the way software dependencies are managed in modern development environments, and they can have serious consequences for the security and integrity of software systems. To protect against these attacks, developers and organizations should use package managers that have built-in security features such as digital signing and verification of packages.
For more information about threats affecting software supply chains, read Software Supply Chain Risks for Low- and No-Code Application Development.