Dependency confusion

A simple loophole discovered by Alex Birsan and Justin Gardner

Last year, security researcher Alex Birsan came across an idea when working with another researcher Justin Gardner.

Gardner had shared with Birsan a manifest file, package.json, from an npm package used internally by PayPal.

Birsan noticed some of the manifest file packages were not present on the public npm repository but were instead PayPal’s privately created npm packages, used and stored internally by the company.

On seeing this, the researcher wondered, should a package by the same name exist in the public npm repository, in addition to a private NodeJS repository, which one would get priority?

To test this hypothesis, Birsan began hunting for names of private internal packages that he could find in manifest files on GitHub repositories or in CDNs of prominent companies but did not exist in a public open-source repository.

The researcher then started creating counterfeit projects using the same names on open-source repositories such as npm, PyPI, and RubyGems.

Every package published by Birsan was done so under his real account and clearly had a disclaimer in place, stating “This package is meant for security research purposes and does not contain any useful code.”

Researcher hacks over 35 tech firms in novel supply chain attack

Now here’s the kicker

Birsan soon realized, should a dependency package used by an application exist in both a public open-source repository and your private build, the public package would get priority and be pulled instead — without needing any action from the developer.

Researcher hacks over 35 tech firms in novel supply chain attack

Yikes!