依赖混淆

Reading time: 4 minutes

tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE)

支持 HackTricks

基本信息

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

  • 拼写错误：导入**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中被发现（阅读此博客文章中的详细信息）。
AWS通过允许指定库是内部还是外部来修复此问题，以避免从外部仓库下载内部依赖。

查找易受攻击的库

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

参考

tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE)

支持 HackTricks