nformation security expert Alex Birsan talked about a new problem , which is a variation of the attack on the supply chain, called the dependency confusion (confusion of dependencies) or substitution attack (substitution attack). For detecting this method of attacks, the researcher has already received more than $ 130,000 from various companies through bug bounty programs. The fact is that, using this problem, the specialist was able to upload his own (harmless) code to the systems of Microsoft, Apple, PayPal, Shopify, Netflix, Yelp, Tesla, Uber and other companies.
The essence of dependency confusion is simple: malware from open source repositories (including PyPI, npm and RubyGems) is automatically distributed further along the entire supply chain, penetrating into internal applications of companies without any user involvement. This is what distinguishes the attack from the usual typesquatting.
This simple idea of Birsan was pushed last year by his colleague, another information security expert Justin Gardner. He shared with Birsan the package.json manifest file from the npm package used internally by PayPal. It turned out that some of the packages from the manifest are not in the public npm repository, they are private packages created by PayPal engineers, and they are used and stored only within the company.
Looking at this, Birsan wondered if a package with the same name should exist in the public npm repository, and if so, which one would eventually take precedence? To test his theory, the researcher started looking for the names of other private packages that can be found in manifest files in GitHub repositories or CDNs of well-known companies, but which are not in the public repositories.
After discovering several such targets, Birsan began creating fake projects with the same names in npm, PyPI and RubyGems (although Birsan notes that other package managers, including JFrog and NuGet, are also vulnerable). The expert created these fakes from under his account and accompanied by an explanation that they were intended solely for security research and did not contain any useful code.
This experiment showed that if a dependency package used by an application exists in both a public open source repository and a private build, the public package eventually gets priority and will be used without any action from the developer. It also turned out that in the case of PyPI packages, the higher version takes precedence no matter where it is located.
Then, using the same tactics, Birsan launched successful attacks against Microsoft, Apple, PayPal, Shopify, Netflix, Tesla, Yelp, Uber and other big companies, simply by publishing packages with the same names as the packages used internally.
“Such vulnerabilities and gaps in automated build or install tools could lead to public dependencies being mistaken for internal dependencies of the same name,” Birsan told Bleeping Computer .
All of the investigator’s test packages contained preinstalled scripts that automatically run a script to retrieve identifying information from the “infected” machine, right after the package pool. Realizing that his scripts would establish connections from secure corporate networks, Birsan decided to bypass security mechanisms by using DNS to retrieve data.
An example of such a script can be seen in the illustration below: it informed the researcher that the IP address from which the request originated belongs to PayPal, and also reported the username and home directory of the affected system.
After collecting the data and making sure that he was right, the researcher began to communicate his findings to vulnerable companies, receiving rewards through bug bounty programs. For example, PayPal has already published an expert report on HackerOne and paid him $ 30,000; Yelp also confirmed Birsan ‘s findings and rewarded him with $ 15,000.
But Microsoft is perhaps the most serious about dependency confusion. This issue has been assigned an identifier the CVE-2021-24105 (for Azure Artifactory), and the company has not only paid an expert $ 40 000, but also published its own white paper , which describes in detail the problem and suggests ways to address it. In particular, Microsoft engineers recommend minimizing risks by protecting private packages using controlled areas in public repositories, as well as using client-side verification (versioning, integrity checking).