Recently, the Biden White House released an Executive Order detailing new requirements to address cybersecurity and secure software development, as it relates to national security. This order addresses a variety of issues on detection, reporting, remediation, and standards, including the increasing attacks on software supply chains. However, one recent and worrying trend is an attack that the provisions in the executive order may not be able to stop: Dependency Confusion.
To help illustrate this problem for both the software industry and the broader open source community, we're revisiting a talk about Dependency Confusion with Sonatype's CTO Brian Fox, Field CTO Ilkka Turunen, and security researcher Ax Sharma. In it, they discuss the progression of a recent, especially effective supply chain attack on the JavaScript-focused npm repository, as well as how to prevent future attacks.
What happened with npm?
In early February 2021, a vulnerability was revealed in the npm repository, infiltrating major technology companies, including Microsoft, Tesla, and Netflix. Although 35 companies were named, the issue affected many more, with companies scrambling to address the issue and hundreds of similar copycat efforts appearing on the npm repository.
A legitimate disguise
In the months before the announcement, Sonatype detected suspicious packages posted by researcher Alex Birsan. The packages were proactively marked as potentially malicious by Sonatype software as a concern and flagged for review. When contacted, Alex responded that affected groups were taking action ahead of a full disclosure.
Once revealed, Brisan's work exposed a weakness in open source repositories where company internal package names were discovered or speculated. Then, it was a simple matter of creating those same-name packages in an external repository. Once posted, company systems automatically elected for the external software sources – the ones posted by Alex.
"It's a simple method: essentially just pretending to be someone you know and going out into the public registry. And it was brutally effective," Ilkka explains.
Although these unofficial packages Alex posted contained no harmful code, the same process can be used to distribute a variety of malware by bad actors. The issue further highlights an ongoing problem in open source authentication and indications of clear ownership by reputable developers.
Three waves of security disclosures
In a series of now-familiar phases after a discovery of this type, the team observed it's disclosure, duplication by imitators, and finally attacks.
Noting the unusual speed of this particular attack, Ilkka noted, "within 24 hours, we already started seeing copycats appear."
A security concern's discovery and validation represents the first wave, giving way to similar efforts by other submitters in wave two. These "copycat" efforts seek to gather bug bounties beyond those initially affected.
The third wave of harmful submissions happened within days, with more than 275 malicious packages at first and then thousands more after that.
Ilkka shared, "when it is announced that there's an actual malicious disclosure, the copycats [have become] attackers so your time to turn around and respond is even shorter. […] I don't think there's a case to be made that grabbing Bash history in the etc/shadow password files was 'white hat' (legitimate). There's no good reason for that."
Solutions and mitigation
While routing rules can manage some of the issues around this for internal repositories, these require manual adjustment and quickly go out of date, so automation is necessary to keep on top of this issue.
Sonatype's tools to avoid dependency confusion include Sonatype Nexus Repository's dependency/namespace confusion checker and Sonatype Repository Firewall, which can quarantine suspicious or malicious open source components before they even enter your repository. Security Researcher and Developer Advocate Ax Sharma also encourages users to take steps to control public repository naming. He suggests "squatting" your own private dependencies on public repositories before an adversary publishes their own.
Over the horizon: Repository validation
The team noted that npm is not the only repository service affected, with similar issues appearing on PyPI, RubyGems, and elsewhere.
The double-edged sword of being easy to publish content to these services also means they are subject to issues like the Dependency Confusion attack. Sonatype co-founder and CTO Brian Fox also notes how validation steps can be useful, which has been policy for the Central repository over the last 15 years:
"Maven has named spaces and that we match that to the coordinates of the domain, so we lean on the domain registrars to make sure that somebody can't come along and publish as [an official source]," he explained. "That's what Alex and all the copycats did."
Brian added, "it creates a little bit of friction on the publish side but, as a consumer, it means somebody [has] validated that there is a correlation between the name of the named space and the components that are being published. Doesn't mean that it's perfect – there are challenges – but we do take care to at least try to validate they are who they say they are, so that's why this [issue] hasn't happened in a big way on [Maven] Central yet."
While we've learned more about this issues since it first appeared in February, it can be confusing (pun intended). If you have questions about combating dependency confusion attacks or any of the recent software supply chain attacks, don't hesitate to get in touch (or comment below). We'd love to chat with you about what we're seeing.
You can watch the full talk on demand: How to Avoid the 'Dependency Confusion' Software Supply Chain Hack, including a demonstration of how the Sonatype Platform software is used to block the download of a questionable package.
