Just three days ago on February 9, 2021, Sonatype released our findings on Alex Birsan's research in which he used the "dependency or namespace confusion" technique to push his malicious proof-of-concept (PoC) code to internal development builds of over 35 major tech organizations including Microsoft, Apple, Tesla, Uber and others.
For his ethical research efforts, the researcher also made over $130,000 in bug bounties.
With the news making headlines, it didn't take long for other researchers to start imitating Birsan’s open source software supply chain attack research.
Within 48 hours of the news reports, Sonatype's automated malware detection systems, part of Sonatype Intelligence, began flagging over 275 copycat npm packages published by different authors that imitate Alex Birsan's proof-of-concept (PoC) research. We are actively seeing more of these packages coming in every few hours.
Sonatype has exclusively spotted these npm packages from multiple, pseudonymous authors claiming these are for "security research purposes only," in the style of Birsan.
But, it is important to note, any adversary could be publishing outright nefarious packages to public open source repositories and disguising them as having been published for "research purposes."
Image: new npm copycat packages have emerged imitating Birsan's research
Not only do most of these packages contain identical code that makes callbacks to the researcher's server over DNS, they have the exact same structure, version numbering, code comments and "research purposes only" disclaimers.
Another noteworthy observation is that some of these npm packages are named after the RubyGems packages that Birsan had published in his PoC attack. For example, the "shopify-cloud" npm package by this new author copies the "shopify-cloud" gem that had earned the researcher a $30,000 bug bounty.
Image: A "shopify-cloud" npm component published by a different author imitates Birsan's "shopify-cloud" RubyGem
The code for the "shopify-cloud" npm package has been analyzed by the Sonatype Security Research team and is shown below. Again, the code attempts to exfiltrate the IP address, username, and current working directory path of the infected system.
Image: Copycat "shopify-cloud" package with identical code as Birsan's PoC code
A few other examples include the package names containing the term "idms," referring to the set of private npm dependencies used by Apple.
As the copycats made their way into npm, due to a lack of stringent namespace verification, it didn't take long for Sonatype's automated malware detection system to start ringing alarms and automatically quarantining these components.
Image: Sonatype automated malware detection system, Release Integrity, illustrated
Consequently, multiple Sonatype security researchers including Ali ElShakankiry, Juan Aguirre, Sebastián Castro, and Danilo Vásquez, promptly jumped on the investigation analyzing these malicious components.
While manual analysis by our researchers was underway, Sonatype customers with the Advanced Development Pack were already protected from the suspicious components as Sonatype Repository Firewall automatically blocks quarantined components as a safeguard, while a researcher review is pending. We have flagged these components as suspicious because we don't believe these are all just bug bounty copycats. Actual attacks could be buried within them, which requires further analysis.
Our findings today reiterate something Sonatype CTO Brian Fox has been stressing for years.
"Ironically, the mechanism used to perpetrate the attack, what's being called namespace confusion or dependency confusion, is one that I'm quite familiar with and has been at the heart of the contention of how we've managed the Maven Central repository for 16+ years vs the users who push back on the standards and just want it to be 'easy like npm'," notes Fox in his Wednesday's blog post.
This is also one of the core reasons why such a copycat attack, abusing dependency or namespace confusion, would be extremely hard to successfully conduct on Maven Central.
For example, if Apache uses a private, internally created Java component called "private_component," which uses the company's private namespace called "org.apache.private," an attacker cannot just publish org.apache.private:private_component to Maven Central without authoritatively verifying they own the private.apache.org domain.
This reverse FQDN (Fully-Qualified Domain Name) based verification approach enforces hygiene and security in the Java ecosystem by enabling rightful owners of a brand or namespace to publish components under the namespace, and keeps adversaries out.
By contrast, Birsan had no issues claiming the "atlassiansox" scope (another term for "namespace" used by npm) using which he was able to publish multiple npm components supposedly named after private components being internally used by Atlassian.
Image: Lack of namespace ownership verification in npm
Although Sonatype believes the authors behind these newly added packages containing minimalist PoC code are after bug bounties, the possibility of adversaries exploiting the same "dependency or namespace confusion" problem is now realistically within sight, which is why automation solutions like Release Integrity have become indispensable.
There are four takeaways from this incident, which happened rather fast following Birsan’s research disclosure news.
According to Sonatype's 2020 State of the Software Supply Chain report, next-generation upstream software supply chain attacks are far more sinister because bad actors are no longer waiting for public vulnerability disclosures. Instead, they are taking the initiative to contribute code to open source projects and then - unbeknownst to the other OSS project maintainers - injecting malicious code. Those code changes then make their way into open source projects that feed the software supply chains of developers around the world.
By shifting their focus upstream (i.e., publishing malicious components in open source repositories), bad actors can infect a single component, which will then be distributed downstream using trusted software workflows and transitive dependencies.
Our 2020, report also shows that this is happening at a rapidly increased rate. In fact, there was a 430% increase in upstream software supply chain attacks over the past year. Keeping this in mind, it is virtually impossible to manually chase and keep track of such components.
Sonatype's world-class security research data, combined with our automated malware detection technology safeguards your developers, customers, and software supply chain from infections.
If you're not a Sonatype customer and want to find out if your code is vulnerable, you can use Sonatype's free Sonatype Vulnerability Scanner to find out quickly.
Visit the Sonatype Intelligence Insights page for a deep dive into other vulnerabilities like this one or subscribe to automatically receive Sonatype Intelligence Insights hot off the press.
Edit February 13, 2021 11:11 PM ET: 100+ more copycat packages have been detected in the last few hours with more coming in, raising the total count from the initially reported 150 to over 275 copycats.