Dependency Confusion

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

{% embed url="https://websec.nl/" %}

Basic Information

In summary, a dependency confusion vulnerability occurs when a project is using a library with a misspelled name, inexistent or with an unspecified version and the used dependency repository allows to gather updated versions from public repositories.

Misspelled: Import reqests instead of requests
Inexistent: Import company-logging, an internal library which no longer exists
Unspecified version: Import an internal existent company-requests library , but the repo check public repos to see if there are greater versions.

Exploitation

{% hint style="warning" %} In all cases the attacker just need to publish a malicious package with name of libraries used by the victim company. {% endhint %}

Misspelled & Inexistent

If your company is trying to import a library that isn't internal, highly probably the repo of libraries is going to be searching for it in public repositories. If an attacker has created it, your code and machines running is highly probably going to be compromised.

Unspecified Version

It's very common for developers to not specify any version of the library used, or specify just a mayor version. Then, the interpreter will try to download the latest version fitting those requirements.
If the library is a known external library (like python requests), an attacker cannot do much, as he won't be able to create a library called requests (unless he is the original author).
However, if the library is internal, like requests-company in this example, if the library repo allows to check for new versions also externally, it will search for a newer version publicly available.
So if an attacker knows that the company is using the requests-company library version 1.0.1 (allow minor updates). He can publish the library requests-company version 1.0.2 and the company will use that library instead of the internal one.

AWS Fix

This vulnerability was found in AWS CodeArtifact (read the details in this blog post).
AWS fixed this by allowing to specify if a library is internal or external, to avoid downloading internal dependencied from external repositories.

Finding Vulnerable Libraries

In the original post about dependency confusion the author searched for thousands of exposed package.json files containing javascript project’s dependencies.

References