Dependency Confusion

This blog post is written by Emil Kylander Edwartz, Security Consultant at Sentor with multiple years of experience within security testing. He will delve into the topic of security issues arising from software developers' utilization of dependencies.

In the world of software development, dependencies have a crucial role. Developers use dependencies to boost productivity because they don’t need to reinvent the wheel. For example, someone already built a package to send a web request, so why create your own? But what happens when this system gets abused by criminal hackers? This blog article will cover how this supply chain attack - also known as Dependency Confusion - works, unique Swedish statistics, and what you can do to protect yourself.

How does Dependency Confusion work?

As we already established, packages are essential for productivity - but packages don’t need to be publicly available. A development team can create private repositories for their internal packages. Internal packages could be components with specific business logic without reason to be public, potentially harming the company.

Here comes the issue; let’s exemplify this. A webshop called “Tireless Tires” sells tires on the web. They have a private package for calculating discounts for specific items and customers. They call this a “discount-calculator,” they have published this to an internal repository called repo.tirelesstires.com. Because of this, they can easily share this package between projects in the development team. This package has version 1.0.0.

Now, let’s say a fierce competitor wants to gain access to Tireless Tires systems; they might figure out that they have a private package called “discount-calculator”. Perhaps Tireless Tires accidentally exposed package.json or composer.json or disclosed the package name in the frontend code on the website.

The competitor wasted no time registering the same component name in a public package manager but increased the version number to 1.0.1. Here’s the issue: package managers first check the public repository; if this doesn’t exist, it checks the private repository. Unfortunately for Tireless Tires, they also added a backdoor so they could remotely access the backend environments of Tireless Tires.

Now it’s a waiting game. The competitor needs to wait till either of these comes true:

1. Tireless Tires deploys updates to its webshop, which will trigger a CI/CD pipeline and update the dependencies
2. A developer from Tireless Tires updates their packages
3. Tireless Tires has automatic updates on dependencies or plugins
4. An employee on Tireless Tires accidentally updates the dependency

When either of these situations comes true, the competitor has successfully hacked Tireless Tires through a software supply chain attack.

How normal is this type of vulnerability?

It’s implicitly tricky to precisely measure how normal this type of vulnerability is because it’s hard to know how many companies have internal packages and if appropriate security measures are applied. However, Sentor has given it a try by looking at Wordpress plugins because Wordpress is affected by this type of security issue. By analyzing 10,000 Swedish WordPress installations, Sentor discovered that 773 websites had private plugins, and the plugin name was publicly available by looking at the HTML code.

Ocra Security reports that 49% of the scanned assets are vulnerable to Dependency Confusion.

How to defend against these types of attacks

Dependency Confusion is a complex issue without a single and straightforward fix. Below are some steps that can help with securing this issue.

1. Reserve a namespace if the package manager supports it
2. Register a public package with the same name as your internal package
3. Use checksum validation to make sure that the correct package is pulled
4. Prevent your private repository from forwarding the request to a public repository
5. Manually update dependencies and verify that the right package has been installed

Sentor can help secure your development process and validate that the issue no longer persists. Contact us, and we will get back as soon as possible.