Dependency attacks aren't slowing down
Ever since the dependency confusion (or namespace confusion) technique gained widespread attention in early 2021, we are yet to see the momentum around these attacks slow down.
The extensive eight-month ethical hacking project by researcher Alex Birsan, ended up in the researcher hacking more than 35 big tech firms via this simple technique and walking away with over $130,000 in bug bounties.
The next in line was open source "vigilantes," hijacking the technique for their cause.
Last year, a pseudonymous user RemindSupplyChainRisks polluted PyPI and npm registries with over 5,000 packages in an attempt to educate the wider community of security threats to open source repositories.
Within 72 hours of Birsan's disclosure, Sonatype saw 300+ copycat packages — not from Birsan, flood npm. After seeing the earning potential, bug bounty hunters jumped on the wagon to capitalize on the technique too.
What may have started out as a research project by a bug bounty hunter was soon abused by threat actors, now looking to target popular companies to exfiltrate sensitive files, such as .bash_history and /etc/shadow, as previously discovered by Sonatype.
In the following weeks, we saw upwards of 10,000 copycat packages posted on npm and PyPI ecosystems — some of these posted by open-source software 'activists' to spread awareness of the security risks posed by this technique, whereas others were outright malicious targeting big names.
Just last month we reported seeing more than 1,200 dependency confusion packages flooding PyPI.
And it hasn’t stopped here.
As of today, Sonatype's automated malware detection systems have caught upwards of 63,000 packages — these include dependency confusion copycats, malicious packages (containing embedded malware), and suspicious typosquats, with the majority of these leveraging the dependency confusion technique.
Whenever Sonatype has come across malicious or suspicious packages that require immediate remediation, we have promptly notified the corresponding repository maintainers and suggested these be removed.
In the case of dependency confusion packages, we saw many candidate packages targeting popular companies, brands, or OSS projects.
The internal structure of almost all dependency confusion packages is nearly identical in functionality. The source code attempts to communicate with the package publisher’s server over DNS or HTTP(S) and sends basic information, such as the IP address of the system that ran the package, username, and other fingerprinting information that can help the package creator identify if they were able to successfully reach their target.
Why are these attacks not going away?
Quite simply, we believe that dependency confusion attacks are here to stay because of:
- Low barriers to entry: Publishing to npm, PyPI, and similar open source repositories are open to everyone — that includes good-faith researchers and adversaries.
- The simplicity of attack: Identifying the names of your private dependencies is the only prerequisite needed for the bug bounty hunter or the attacker. After the package creator is banking on your software builds being susceptible to dependency confusion technique, and pull in their publicly available package over your private, internal dependency.
- High chance of success: Birsan's massive $130,000 bug bounty payout and success with over 35 big firms may have reinforced the effectiveness of techniques and the reward potential of the technique to both ethical hackers and threat actors.
As such, much like typosquatting, this attack vector remains an attractive target for actors looking for quick results while investing a minimum amount of resources.
What can be done to combat dependency confusion?
Strict namespacing checks are one of the deterrents that, when implemented by open source registries and your projects alike, can prevent dependency confusion attacks. For example, if you publish all of your private dependencies under @yourcompany/ scope, and should a public registry like npm only allow authorized parties to publish(public) packages under @yourcompany/, the possibility of an attacker abusing the dependency confusion technique is nearly eliminated.
Alternatively, automated solutions that can spot dependency conflicts between your internal/private dependencies and public packages (there's a GitHub script for that!) can be used to effectively thwart malicious dependencies from entering your build. Users of Sonatype Repository Firewall can rest easy knowing that such PoC candidates would automatically be blocked from reaching their development builds.
