Last week, a researcher demonstrated a new supply chain attack that involved executing fake code on networks of some of the world’s largest companies, including Apple, Microsoft and Tesla. Now fellow researchers scour the internet with copycat packages, more than 150 of which have been detected so far.
The technique was unveiled last Tuesday by security researcher Alex Birsan. Its so-called dependency confusion or namespace confusion attack starts with 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 download and install the counterfeit code automatically.
Automatic pwnage
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 colleagues, developers are saved the hassle and expense of creating the code themselves. The developer’s code is automatically downloaded and contains the dependency, or any update to it, from the developer’s local machine or from a public repository.
Birsan scoured Internet forums, JavaScript code, accidentally published internal packages, and other resources to find the names of code dependencies used in 35 companies’ software. He then uploaded his own code to NPM, PyPI or Ruby Gems with the same dependency names. In other words, the researcher cracked down on the companies’ authentic package name. The researcher eventually received $130,000 in bug bounties.
By giving the packages version numbers higher than the authentic ones, the targeted companies automatically downloaded and executed Birsan’s counterfeit packages.
“The success rate was just 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: cracking valid internal package names was a virtually foolproof method of breaking into the networks of some of the largest technology companies. out there, allowing remote code execution and potentially allowing attackers to add backdoors during builds.
Within two days of Birsan publishing his results, security firm Sonatype said last Friday, other developers or researchers had carried out copycat attacks and placed 150 similar packages with cracked names in NPM.
How it works
Package managers typically accept dependencies listed as names and try to parse developers’ intentions. The administrators look for dependencies both on the local computer where the project is stored and on the web-accessible directory associated with the package manager.
“The problem of dependency confusion is an inherent design flaw in the native installation tools and DevOps workflows that pull dependencies into your software supply chain,” Sonatype researchers wrote in a previous article on Birsan’s attack. “In this context, dependency confusion refers to the inability of your development environment to distinguish between a private, internally created current package in your software build and a package of the same name available in a public software repository.”
Sonatype researchers explained the technique this way:
For example, let’s assume that your application uses an internal, privately made PyPI component called foobar (version 1) as a dependency. Should an unrelated component with the same name but with a higher version number foobar (version 9999) be later published to the PyPI downloads public repository, the default configuration of PyPI development environments dictates that the higher version foobar be downloaded as a dependency.
In this case, that would mean that the attacker’s counterfeit foobar package with a higher version number silently and automatically finds its way into your software build.
So-called typo-cracking attacks have been around for years. They upload code to public repositories and use names similar to those of legitimate packages in the hopes that a developer makes a typo or clicks on a malicious link that causes the fake code to download. The advantage of Birsan’s dependency confusion technique is that it does not rely on human error to work.
Although the affected companies did not discover the counterfeit, Sonatype did. After consulting with Birsan, the company learned that the fake dependencies were part of a benign experiment.
Proof of concept
Birsan found that the 35 affected companies were using locally stored dependencies that were not available in the public directory. When he uploaded his own proof-of-concept malicious code to a public repository with the same name as the legitimate dependency and a higher version number, the company’s software was automatically installed and run.
To prevent companies from violating vulnerability reporting policies, Birsan’s code limited its activities to sending the user name, host name, and current patch of each unique installation to the researcher. He was also authorized to test the security of all 35 companies, either through public bug bounty programs or private agreements.
To ensure that security did not 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 traffic comes at least four years after malware’s use of DNS exfiltration came to the attention of researchers.
Canadian ecommerce company Shopify automatically installed a Ruby Gem called shopify cloud within hours of Birsan making it available in the Ruby Gems repository. Meanwhile, multiple machines within Apple’s network were executing code that Birsan had 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 in bounties each.
Sonatype has here a list of steps developers can take to prevent dependency confusion attacks. The main defense is that repositories enforce mandatory namespace and scope authentication. One verification technique is the reverse use of the fully qualified domain name, which allows legitimate owners of a brand or namespace to publish components in that namespace while keeping opponents out.