mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
49 lines
3.0 KiB
Markdown
49 lines
3.0 KiB
Markdown
# Dependency Confusion
|
||
|
||
{{#include ../banners/hacktricks-training.md}}
|
||
|
||
|
||
## 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
|
||
|
||
> [!WARNING]
|
||
> In all cases the attacker just need to publish a **malicious package with name** of libraries used by the victim company.
|
||
|
||
### 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 **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
|
||
|
||
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
|
||
|
||
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://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610)
|
||
- [https://zego.engineering/dependency-confusion-in-aws-codeartifact-86b9ff68963d](https://zego.engineering/dependency-confusion-in-aws-codeartifact-86b9ff68963d)
|
||
|
||
|
||
{{#include ../banners/hacktricks-training.md}}
|
||
|
||
|
||
|