依赖混淆

{% hint style="success" %} 学习和实践 AWS 黑客技术：HackTricks 培训 AWS 红队专家 (ARTE)
学习和实践 GCP 黑客技术：HackTricks 培训 GCP 红队专家 (GRTE)

支持 HackTricks

查看 订阅计划!
加入 💬 Discord 群组 或 Telegram 群组 或关注我们的 Twitter 🐦 @hacktricks_live.
通过向 HackTricks 和 HackTricks Cloud GitHub 仓库提交 PR 来分享黑客技巧。

{% endhint %}

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

基本信息

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

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

利用

{% hint style="warning" %} 在所有情况下，攻击者只需发布一个 恶意包，名称与 受害公司使用的库相同。 {% endhint %}

拼写错误与不存在

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

未指定版本

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

AWS 修复

此漏洞在 AWS CodeArtifact 中被发现（阅读 此博客文章中的详细信息）。
AWS 通过允许指定库是内部还是外部来修复此问题，以避免从外部仓库下载内部依赖。

查找易受攻击的库

在 关于依赖混淆的原始文章 中，作者搜索了数千个暴露的 package.json 文件，包含 JavaScript 项目的依赖。

参考文献