5 Ways Your Software Supply Chain is Out to Get You, Part 4: Dependency Confusion

by Chris Prevost on April 29, 2021

Previously, we discussed how three kinds of supply chain attack methods, Vendor Compromise, Exploit Third Party Applications, and Exploit Open Source Libraries are threatening software supply chains, passing risk downstream to the organizations and users that trust and depend on them. In this fourth installment, we explain the concept of Dependency Confusion.

Dependency Confusion

In early 2021, security researcher Alex Birsan (@alxbrsn) unveiled another supply chain attack vector named “Dependency Confusion.” It’s a clever and incredibly simple technique that takes advantage of how modern software programs are assembled – once again showing how assumptions can easily be taken advantage of.

Software programs are created with an array of specialized software tools. The source code itself is created with purpose-built text editors that make the process of writing code more efficient. Once the code has been written it is stored in a version-controlled repository. Code reuse is a constant goal in software development, therefore common or utility code is bundled into “libraries” or packages that can be incorporated into many software applications. To create the application, “build tools” are invoked to pull the appropriate code and libraries from their respective repositories. The code is then compiled, assembled, and packaged for delivery. Additional tools are used to run automated tests and push the application to designated deployment environments – testing, staging, production, etc. This happens dozens of times per day for a typical application.

Open-source libraries are simply bundles of generally useful utility code that are made freely available through the use of “public” repositories. With the overwhelming majority of software applications containing open-source software, an organization’s build tools must pull code from both “private” (only accessible to the organization that’s producing the application) and public repositories.

The trick to Dependency Confusion is to take advantage of how the build tool decides where to look for library code and how to decide which version to pick if there are duplicates. If an attacker registers a package in a public repository with the same name as a package in a private repository, the attacker’s package may be “pulled” by the build tool instead of the intended internal package. If the attacker’s package is named with a higher version number, the build tool may pull the attacker’s library instead of the intended internal library with a lower version number. Given the complexity of modern software applications and their heavy reliance upon open-source, this attack vector can be surprisingly effective.

Sponsorships Available

The results can be devastating. It only takes a single wrong pull to have an attacker’s code run on the machine running the build tool – a developer’s laptop, a server in AWS, etc. Using this method, Alex was able to confirm that his proof of concept code was able to send data to his simulated attacker server from internal servers at virtually every company he targeted including Apple, Microsoft, Netflix, PayPal, Shopify, Tesla, and Uber. Within 48 hours following the publication of this technique, hundreds of copycat open source packages were found attempting the same technique.

Imperva RASP

Imperva Runtime Application Self-Protection (RASP) offers a compelling way forward. Delivered as a lightweight software plugin, RASP attaches to virtually any type of application whether a third party, open-source or bespoke. Tightly coupled with the application and requiring no external connectivity, RASP protections are consistently applied regardless of where the application is deployed today or in the future. Using a positive security approach, RASP mitigates risk from supply chain attacks by neutralizing malicious software activity including unauthorized network calls, file system access, and execution of commands on the underlying host operating system.

Perhaps this is why the National Institute of Standards and Technology recommends the use of RASP in Special Publication 800-53, section SI-7(17), Security and Privacy Controls for Information Systems and Organizations?