Dependency Confusion
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
基本信息
总之,依赖混淆漏洞发生在项目使用一个 拼写错误、不存在或 未指定版本 的库时,而所使用的依赖库仓库允许从 公共 仓库 获取更新版本。
拼写错误:导入
reqests
而不是requests
不存在:导入
company-logging
,一个 不再存在 的内部库未指定版本:导入一个 内部 存在的
company-requests
库,但仓库检查 公共仓库 以查看是否有 更高版本。
利用
在所有情况下,攻击者只需发布一个 恶意包,名称与 受害公司使用的库相同。
拼写错误与不存在
如果您的公司试图 导入一个不是内部的库,那么库的仓库很可能会在 公共仓库 中搜索它。如果攻击者创建了它,您的代码和运行的机器很可能会被攻陷。
未指定版本
开发者 不指定任何版本 的库,或仅指定一个 主要版本 是非常常见的。然后,解释器将尝试下载符合这些要求的 最新版本。
如果库是一个 已知的外部库(如 Python 的 requests
),攻击者 无法做太多,因为他无法创建一个名为 requests
的库(除非他是原作者)。
然而,如果库是 内部的,如本例中的 requests-company
,如果 库仓库 允许 检查新版本也在外部,它将搜索一个公开可用的更新版本。
因此,如果一个 攻击者知道 公司正在使用 requests-company
库 版本 1.0.1(允许小版本更新)。他可以 发布 库 requests-company
版本 1.0.2,而公司将 使用该库而不是内部库。
AWS 修复
此漏洞在 AWS CodeArtifact 中被发现(阅读 此博客文章中的详细信息)。 AWS 通过允许指定库是内部还是外部来修复此问题,以避免从外部仓库下载内部依赖。
查找易受攻击的库
在 关于依赖混淆的原始文章 中,作者搜索了数千个暴露的 package.json 文件,包含 JavaScript 项目的依赖。
参考文献
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
Last updated