Last week, a researcher demonstrated a new supply-chain attack that executed counterfeit code on networks belonging to some of the biggest companies on the planet, Apple, Microsoft, and Tesla included. Now, fellow researchers are peppering the Internet with copycat packages, with more than 150 of them detected so far.
The technique was unveiled last Tuesday by security researcher Alex Birsan. His so-called dependency confusion or namespace confusion attack starts by placing malicious code in an official public repository such as NPM, PyPI, or RubyGems. By giving the submissions the same package name as dependencies used by companies such as Apple, Microsoft, Tesla, and 33 other companies, Birsan was able to get these companies to automatically download and install the counterfeit code.
Dependencies are public code libraries or packages that developers use to add common types of functionality to the software they write. By leveraging the work of thousands of their open source peers, developers are spared the hassle and expense of creating the code themselves. The developer’s code automatically downloads and incorporates the dependency, or any update to it, either from the developer’s local computer or from a public repository.
By giving the packages version numbers that were higher than the authentic ones, the targeted companies automatically downloaded and executed Birsan’s counterfeit packages.
“The success rate was simply astonishing,” Birsan wrote. He added:
From one-off mistakes made by developers on their own machines, to misconfigured internal or cloud-based build servers, to systemically vulnerable development pipelines, one thing was clear: squatting valid internal package names was a nearly sure-fire method to get into the networks of some of the biggest tech companies out there, gaining remote code execution, and possibly allowing attackers to add backdoors during builds.
Within two days of Birsan publishing his results, security company Sonotype said last Friday, other developers or researchers had carried out copycat attacks and put 150 similarly name-squatted packages in NPM.
How it works
Package managers typically accept dependencies listed as names and attempt to parse developers’ intentions. The managers look for dependencies both on the local computer where the project is stored and the Internet-accessible directory belonging to the package manager.
“The dependency confusion problem is an inherent design flaw in the native installation tools and DevOps workflows that pull dependencies into your software supply chain,” Sonotype researchers wrote in an earlier writeup on Birsan’s attack. “In this context, dependency confusion refers to the inability of your development environment to distinguish between a private, internally-created present package in your software build, and a package by the same name available in a public software repository.”
Sonotype researchers went on to explain the technique this way:
For example, let’s assume your application uses an internal, privately-created PyPI component called foobar (version 1) as a dependency. Later, should an unrelated component by the same name but higher version number foobar (version 9999) be published to the PyPI downloads public repository, the default configuration of PyPI development environments dictates that the foobar with the higher version be downloaded as a dependency.
In this case, that would mean, the attacker’s counterfeit foobar package with a higher version number would silently and automatically make its way into your software build.
So-called typo-squatting attacks have existed for years. They upload code into public repositories and use names that are similar to the names of legitimate packages in the hopes a developer will make a typo or click on a malicious link that causes the fake code to be downloaded. The advantage of Birsan’s dependency confusion technique is that it doesn’t rely on human error to work.
While the affected companies didn’t spot the counterfeit, Sonotype did. After checking with Birsan the company learned that the bogus dependencies were part of a benign experiment.
Proof of concept
Birsan found that the 35 affected companies used locally stored dependencies that weren’t available in the public directory. When he uploaded his own proof-of-concept malicious code to a public repository using the same name as the legitimate dependency and a higher version number, the companies’ software automatically installed and ran them.
To keep from running afoul of companies’ vulnerability-reporting policies, Birsan’s code limited its activities to sending the username, hostname, and current patch of each unique installation to the researcher. He also had permission to test the security of all 35 companies, either through public bug bounty programs or private agreements.
To ensure security defenses didn’t block the information from leaving the target company’s network, Birsan’s PoC code hex-encoded the data and sent it in a DNS query. The companies’ failure to block the traffic comes at least four years after the use of DNS exfiltration by malware came to the attention of researchers.
Canadian ecommerce company Shopify automatically installed a Ruby Gem named shopify-cloud within a few hours of Birsan making it available in the Ruby Gems repository. Meanwhile, multiple machines inside Apple’s network executed code Birsan uploaded to NPM. Birsan said the affected Apple projects appeared to be related to Apple ID, the company’s authentication system. Both Shopify and Apple awarded Birsan $30,000 bounties each.
Sonotype has a list of steps here that developers can take to prevent dependency confusion attacks. Chief among the defenses is for repositories to enforce mandatory namespace and scope verification. One verification technique is the reverse use of the fully qualified domain name, which allows rightful owners of a brand or namespace to publish components in that namespace while keeping adversaries out.