mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
44 lines
2.6 KiB
Markdown
44 lines
2.6 KiB
Markdown
# 依赖混淆
|
||
|
||
{{#include ../banners/hacktricks-training.md}}
|
||
|
||
## 基本信息
|
||
|
||
总之，依赖混淆漏洞发生在项目使用了一个**拼写错误**、**不存在**或**未指定版本**的库，并且所使用的依赖库仓库允许从**公共**仓库**获取更新版本**。
|
||
|
||
- **拼写错误**：导入**`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)
|
||
|
||
{{#include ../banners/hacktricks-training.md}}
|