通过npm包别名探索依赖性混淆攻击的延伸

Nishant Jain 2021年11月4日

依赖性混淆攻击是开源供应链安全攻击的一种形式，攻击者利用了软件包管理器安装依赖性的方式。在之前的一篇文章中，我们探讨了如何检测和防止npm上的依赖混淆攻击，以维护供应链安全。

在这篇文章中，我们将介绍利用npm的包别名功能对依赖关系混乱问题的扩展。由npm命令行应用程序提供和指导的这种软件包别名能力，是一种仅由用户在不同别名下安装软件包的方式。根据npm自己的文档，参考下面的例子。

npm install my-react@npm:react

这将创建以下package.json 条目。

dependencies: {
  “my-react”: “npm:react”
}

npm包别名的反响在其他与包相关的工具处理包清单的方式中显现出来，事实上，也适用于官方的npmjs.org注册表本身。

进行npm包别名攻击

让我们重现npm包别名攻击的影响，以证明这如何导致依赖性混乱和恶意流氓包的安装。

我们首先创建一个名为deneuve-package-parent 的包，安装两个不同版本的deneuve-package-test 包：1.0.0 和 1.2.0 版本。1.0.0版本被安装，是因为它被别名为一个捏造的包deneuve-package-private ，这要感谢npm包别名。

这在npmjs.com上被解析为deneuve-package-parent 的依赖项之一。

考虑将以下package.json 作为上述软件包依赖关系树的完整参考。

{
  "name": "deneuve-package-parent",
  "version": "1.2.0-beta",
  "description": "This is the parent package!",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Hello\""
  },
  "author": "deneuve@wearehackerone.com",
  "license": "ISC",
  "dependencies": {
    "deneuve-package-test": "^1.2.0",
    "deneuve-package-private": "npm:deneuve-package-test@1.0.0"
  }
}

我们继续前进并将该包发布到npmjs。然后我们浏览了依赖关系列表。

正如你所看到的，npmjs注册表上的依赖项列表实际上将捏造的别名deneuve-package-private 作为依赖项的名称之一。

dependency confusion attacks on npmjs

上面的截图显示了一个名为deneuve-package-private 的依赖关系，我们在package.json ，而不是作为一个真正的依赖关系创建的别名。这个别名（被用作包名）实际上并不存在于npmjs注册表上......除非有人将其公布出来而这正是供应链安全问题的关键所在。

Dependency confusion attack on npmjs results in 404 page for a seemingly real dependency

这就引出了一个问题：如果有人发现了这样的别名包，然后将其作为恶意包发布到npm上怎么办？困惑的用户可能会看到npmjs官方软件包页面上列出的依赖关系，并可能通过在他们的开发机器上简单地运行本地npm安装来消费它们。

$ npm install deneuve-package-private

我们继续前进，向npmjs注册表发布了一个该名称的空包。正如你所看到的，如果你浏览Dependents标签，它实际上链接到了原始包，在它的一个依赖的别名中提到了它。

Dependency confusion attacks on npmjs due to wrong context of npm package alias

这应该引起任何处理包名的开发者工具的注意，比如npmjs注册表本身，以确保他们不会在包名方面混淆用户。

关于这个npm漏洞发现的背景

这种形式的供应链攻击最近是由我和安全研究员Mario Stathako发现的，我们向GitHub和npm报告了它。我是一名研究生，一直在花时间研究和开发漏洞赏金安全资源。我也是Snyk大使!马里奥是一名渗透测试员，经常参加夺旗（CTF）和漏洞赏金计划。

依赖性混淆引起了我的兴趣，因为它是如此基本的东西，却有如此大的影响！因此，马里奥和我开始搜索这个问题。因此，马里奥和我开始在HackerOne的私人项目中搜索这个问题。我们想看看在特定时间段过后，公司是如何成功地回应/缓解流行的研究。我们在NPM网站上为攻击构建POC包时发现了一些奇怪的行为，那就是package.json文件对不同包的处理方式，以及它是如何列出该包的依附物和依赖物的。

保护自己免受供应链安全的影响

Snyk已经开发并发布了一个名为snync的开源命令行应用程序，以协助你检测和警告潜在的依赖性混淆（及相关）攻击。你可以在这个npm依赖性混淆检测和预防博客中了解该工具的所有情况。

此外，Snyk Advisor是一个有用的工具，可以标记软件包中的安全问题，跨越其版本，并明确显示一个软件包是否被发现是恶意的。

A malicious package on npm is shown on the Snyk Advisor package page

最后，这里有一些关于开源供应链安全最佳实践的推荐后续阅读。

保护你的开源依赖性

使用Snyk免费扫描您的开源库中的漏洞。

免费注册

SnykCon 2021已经结束了!

重温你喜欢的所有讲座，并查看你没能参加的现场讲座。

现在观看

通过npm软件包别名探索依赖性混淆攻击的扩展