# 依赖混淆

{{#include ../banners/hacktricks-training.md}}

<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>

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

## 基本信息

总之，依赖混淆漏洞发生在项目使用了一个**拼写错误**、**不存在**或**未指定版本**的库，并且所使用的依赖库仓库允许从**公共**仓库中**获取更新版本**。

- **拼写错误**：导入**`reqests`**而不是`requests`
- **不存在**：导入`company-logging`，一个**不再存在**的内部库
- **未指定版本**：导入一个**内部**的**存在**的`company-requests`库，但仓库检查**公共仓库**以查看是否有**更高版本**。

## 利用

> [!WARNING]
> 在所有情况下，攻击者只需发布一个**恶意包，名称与受害公司使用的库相同**。

### 拼写错误与不存在

如果你的公司试图**导入一个不是内部的库**，很可能库的仓库会在**公共仓库**中搜索它。如果攻击者创建了这个库，你的代码和运行的机器很可能会被攻陷。

### 未指定版本

开发者**不指定任何版本**的库，或仅指定一个**主要版本**是非常常见的。然后，解释器会尝试下载符合这些要求的**最新版本**。\
如果库是一个**已知的外部库**（如python的`requests`），攻击者**无法做太多**，因为他无法创建一个名为`requests`的库（除非他是原作者）。\
然而，如果库是**内部的**，如本例中的`requests-company`，如果**库仓库**允许**检查新版本也来自外部**，它将搜索一个公开可用的更新版本。\
因此，如果一个**攻击者知道**公司正在使用`requests-company`库的**版本1.0.1**（允许小版本更新）。他可以**发布**库`requests-company`的**版本1.0.2**，而公司将**使用该库而不是内部库**。

## AWS修复

此漏洞在AWS的**CodeArtifact**中被发现（阅读[**此博客文章中的详细信息**](https://zego.engineering/dependency-confusion-in-aws-codeartifact-86b9ff68963d)）。\
AWS通过允许指定库是内部还是外部来修复此问题，以避免从外部仓库下载内部依赖。

## 查找易受攻击的库

在[**关于依赖混淆的原始帖子**](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610)中，作者搜索了数千个暴露的package.json文件，这些文件包含JavaScript项目的依赖项。

## 参考

- [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)

<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>

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

{{#include ../banners/hacktricks-training.md}}