Bleeping Computer: Researcher hacks over 35 tech firms in novel supply chain attack

Researcher hacks over 35 tech firms in novel supply chain attack
By Ax Sharma. February 9, 2021, 01:04 PM

A researcher managed to breach over 35 major companies' internal systems, including Microsoft, Apple, PayPal, Shopify, Netflix, Yelp, Tesla, and Uber, in a novel software supply chain attack.

The attack comprised uploading malware to open source repositories including PyPI, npm, and RubyGems, which then got distributed downstream automatically into the company's internal applications.

Unlike traditional typosquatting attacks that rely on social engineering tactics or the victim misspelling a package name, this particular supply chain attack is more sophisticated as it needed no action by the victim, who automatically received the malicious packages.

This is because the attack leveraged a unique design flaw of the open-source ecosystems called dependency confusion.

For his ethical research efforts, the researcher has earned well over $130,000 in bug bounties.

A remarkably simple attack revealing serious problems in corporations' open source package distribution systems.

Like most companies using open source software, they develop applications containing both public packages (which come from well-known and trusted Internet repositories) and private packages (developed in-house). In order to maximize reuse of private packages, they are deployed using an internal repository system, which automatically installs and an application's dependent packages, regardless of where they come from.

The problem happens because the internal repository system doesn't seem to distinguish between private and public packages. So if your application is using a private package, and later one a public repository adds a new package with the same name, the system may end up replacing your internal package with the one from the public server. And because automatic updates are common (in order to quickly incorporate bug fixes and security patches), these replacement packages may automatically get installed into publicly accessible applications.

Well that's not right.

Fortunately, this test was from a security researcher, who promptly reported the bugs, but this could just as easily been malware.

I don't think this should be hard to fix. Internal package management systems need to distinguish between public and private packages. When a given package name exists as both a public and a private package, the system *must* always give priority to the private package. It must also alert administrators and owners of affected applications to alert them to the conflics, so appropriate action may be taken. This action may be one or more of:

• Block the public package
• Rename the private package and update all applications using it so they use the renamed package
• Allow application developers to explicitly state in their package manifests if they want to use the public or the private version