The availability of external libraries and packages has increased the efficiency of software development. But behind all of this ease of use comes a critical flaw known as dependency confusion. This vulnerability arises from the posting of an internal package with the same name to a public repository, which can cause unexpected package retrievals when the build is running.
This happens when an attacker uploads a package with the same name as an internal package used in a company’s development environment, either on purpose or accidentally, to a public repository (like PyPI, npm, Maven, etc.). The build process may retrieve the malicious package from the public repository rather than the intended internal package because the majority of package managers give preference to external sources over internal ones.
Integrating a malicious external package into a codebase can result in data breaches, system compromise, or unauthorized access,
In 2021 Alex Birsan a security researcher, revealed how he could use dependency misunderstanding to target well-known corporations like Apple, Microsoft, and Tesla.
These firms, according to Birsan, were using internal package names that bore similarities to packages that were made publicly available on package repositories such as PyPI (for Python) and npm (for Node.js).
During the construction process, Birsan showed that these firms’ systems unintentionally pulled malicious packages from public repositories rather than the intended internal ones, by uploading packages that had the same names as the internal ones but a different version.
As an example, Birsan once published a package called “electron” to the public npm repository, which is also the name of a Microsoft internal package. Microsoft’s build system retrieved Birsan’s malicious package from the public repository and prioritized it above the internal one when it collected requirements for its applications. This might make it easier for hackers to access company networks without authorization, erode security, or damage security.
That’s Risky!!
Risk in Open Source
This weakness becomes especially strong when it comes to open-source software. When working on open-source projects, developers or other contributors frequently and unintentionally expose the project or organization to dependency confusion.
For example, an unintentional inclusion of a malicious package with the same name as an internal dependency used by the project could occur when a contributor works on an open-source project. The build system may retrieve this external package rather than the intended internal one when the project is built or deployed, which could result in possible security lapses, data leaks, or unauthorized access within the open-source project.
As we talked about Alex Birsan above, his research made a solid impact on other researchers to work on this risk. 2021 after this Sonatype found more than 275 malicious npm packages copied, according to the findings of different researchers.
Mitigating the Risk
- To avoid the risk of dependency confusion, the first thing should be Strategic Package Naming, to minimize clashes with public repositories.
- Use manifests or lock files (package-lock.json, yarn.lock) in JavaScript projects to specify dependency versions precisely. By using this procedure, software updates that are not intended are prevented during development.
- Configure package managers to only pull dependencies from approved sources. Access to pre-approved sources is restricted to reduce the possibility of obtaining unverified external dependencies.
- Consider hosting critical packages on internal registries to minimize dependency on public sources and guarantee the use of approved and authenticated code.
The real-life examples and best practices discussed underscore the importance of fortifying security measures at every stage of the software development lifecycle. It is imperative for organizations and individual developers alike to remain vigilant, continually reassess their practices, and prioritize security in every aspect of software development.
Dependency confusion stands as a significant challenge in the complex field of software development, posing a substantial threat to the integrity and security of systems. The potential for unintentional integration of malicious external packages into codebases highlights the critical need for proactive measures and heightened awareness within the development community.
