Dependency confusion, also known as a "substitution attack", is when an attacker registers the same name for an organization's internal library on a public package index in order to send vulnerable or malicious code into the organization's private code repositories.
How does it happen?
If developers use “internal” modules that are not scoped, and the module is available for an attacker to potentially register, there are a few ways an attack can happen.
- A package manager may default to external libraries over internal ones.
- If an internal library is unavailable (for example, when a user forgets to activate the VPN) package managers will look to external libraries.
- When a library is downloaded from a package manager, the first thing the library does is run a post-install script that could include a malicious payload.
How do I fix it?
There are several things you can do to protect your company and code against dependency confusion:
- Treat lists of internal libraries and packages as sensitive information. Since the success of an attack depends on knowing the name of an internal resource, organizations can no longer be casual about where this information is stored and shared.
- Activate namespaced modules. Many package managers, including Maven and npm, now support namespaced modules, which prevents the same name from being used for two different resources.
- Register namespaces on public repositories. Another strategy is to register the names, and similar spellings, of internal libraries and packages on all public repositories being used by the organization, even if the reserved names are never used. This would prevent attackers from tricking a developer into using an identically or similarly named package on a public repository.