# Dependency Confusion

Reading time: 3 minutes

### [Basic Information](https://book.hacktricks.wiki/en/pentesting-web/dependency-confusion.html#basic-information) <a href="#basic-information" id="basic-information"></a>

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](https://book.hacktricks.wiki/en/pentesting-web/dependency-confusion.html#exploitation) <a href="#exploitation" id="exploitation"></a>

In all cases the attacker just need to publish a **malicious package with name** of libraries used by the victim company.

#### [Misspelled & Inexistent](https://book.hacktricks.wiki/en/pentesting-web/dependency-confusion.html#misspelled--inexistent) <a href="#misspelled--inexistent" id="misspelled--inexistent"></a>

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](https://book.hacktricks.wiki/en/pentesting-web/dependency-confusion.html#unspecified-version) <a href="#unspecified-version" id="unspecified-version"></a>

It's very common for developers to **not specify any version** of the library used, or specify just a **major 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](https://book.hacktricks.wiki/en/pentesting-web/dependency-confusion.html#aws-fix) <a href="#aws-fix" id="aws-fix"></a>

This vulnerability was found in AWS **CodeArtifact** (read the [**details in this blog post**](https://zego.engineering/dependency-confusion-in-aws-codeartifact-86b9ff68963d)).\
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](https://book.hacktricks.wiki/en/pentesting-web/dependency-confusion.html#finding-vulnerable-libraries) <a href="#finding-vulnerable-libraries" id="finding-vulnerable-libraries"></a>

In the [**original post about dependency confusion**](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610) the author searched for thousands of exposed package.json files containing javascript project’s dependencies.

### [References](https://book.hacktricks.wiki/en/pentesting-web/dependency-confusion.html#references) <a href="#references" id="references"></a>

* <https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610>
* <https://zego.engineering/dependency-confusion-in-aws-codeartifact-86b9ff68963d>

\\
