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.
Malware detection system pipeline flooded with copycats, Sonatype Repository Firewall blocks by default
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.
Namespace confusion: A major deficiency of open source repositories
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.
TLDR: What do I need to know? And how do I protect myself?
There are four takeaways from this incident, which happened rather fast following Birsan's research disclosure news.
- Sonatype Intelligence has become indispensable: Next-gen Sonatype Intelligence, which powers our suite of products including Sonatype IQ and Sonatype Repository Firewall, by pulling insights from our world-class team of Security Researchers and the Release Integrity malware detection system is at every step ahead of the adversaries looking to infiltrate open source ecosystems for experimental or outright nefarious purposes.
Sonatype customers taking advantage of Sonatype Repository Firewall with Advanced Development Pack policies would be protected from such copycat packages that were automatically quarantined on being discovered shortly after they were published. - Namespacing and ownership verification are not optional: The reason behind Birsan's original attack that let him breach over 35 tech companies succeeding, and the copycat npm packages shortly resurfacing in npm, and potentially other repositories (PyPI, RubyGems, NuGet, etc.) speaks to the importance of namespace verification.
By all means, open source ecosystem should be kept open to everyone who wants to genuinely contribute, but some safeguard is needed to prevent malicious actors from claiming namespaces belonging to an existing brand or company.
Enforcing mandatory namespace/scope verification, such as by using FQDN-based validation, can protect not just your repository, but the entire OSS community, developers, their applications and clients (the entire "ecosystem"). - Squatting your private dependencies doesn't hurt: If you have no other protection or custom configuration for your build tools in place (such as pulling from different repositories for private and public namespaces), consider at least squatting your private dependency names, including namespaces/scopes, on the public open-source repositories before threat actors can claim them.
- Check your build tools configuration: Are your development tools properly configured when it comes to pulling private and public dependencies? Simple scripts can be used to monitor where components are being pulled in from.
In the blog minimizing risk with Sonatype Nexus Repository, my colleague Michael Prescott released tips and a detailed set of routing rules that users of Sonatype Nexus Repository can leverage to keep themselves protected.
Additionally, we've also created a GitHub script to check if you have artifacts containing the same name between your repositories. The script can be used to check if you're affected by a Dependency Confusion Attack.
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.
