A dependency confusion attack (or supply chain attack) occurs when a software installer script is tricked into pulling malicious code file from a public repository instead of the intended file of the same name from an internal repository.
The attack is successful because many package installers, when faced with two different versions of the same file, pick the one with the highest version number.
What is a Dependency?
Dependencies are code modules packaged for easy consumption in application code that you write. It’s a mechanism to enable code reusability for commonly solved problems and are imported into your applications.
Security Researcher Proved the Dependency Confusion Attack Risk
Security researcher Alex Birsan recently used the tactic to push malicious proof-of-concept (POC) code to internal development builds at more than 35 technology companies. When activated, his package simply returned a message that the package is “for security research purposes only.”
One difficulty that cyber criminals—and security researchers—have in deploying a dependency confusion attack is that they must figure out the names of an organization’s internal libraries and modules.
But Birsan was able to find documents that list the names of internal packages at many companies. While organizations may not have considered the lists themselves to be sensitive information, they provided a key through which an attacker (fortunately, an ethical one in this instance) was able to infiltrate the software factory at some of the world’s most technologically advanced companies.
The Attack Flow
From the above image, it can be observed that the Public Package contains Higher version compared to the Private package.
So if the package indexing is not properly done, it will automatically pull the Higher version package from the Public Registry.
See the video below explaining the attack in more detail.
Microsoft Urges Companies to Analyze Internal Package Repositories
Microsoft has published a white paper detailing the dependency confusion technique.
The white paper warns companies about hybrid package manager configurations, where both public and private library sources are used, but also details a series of mitigations that companies can apply to avoid dependency confusions within their build environments.