可疑的维护者揭露了 npm 供应链攻击的线索

大家好，我们又见面了啊~本文《可疑的维护者揭露了 npm 供应链攻击的线索》的内容中将会涉及到等等。如果你正在学习文章相关知识，欢迎关注我，以后会给大家带来更多文章相关文章，希望我们能一起进步！下面就开始本文的正式内容~

这个故事开始于基于 react 的开源文档项目 docusaurus 的维护者 sébastien lorber 注意到对包清单的 pull request 更改。以下是对流行的 cliui npm 包的建议更改：

具体来说，让我们注意使用不熟悉的语法的 npm 依赖项更改：

  "dependencies": {
    "string-width": "^5.1.2",
    "string-width-cjs": "npm:string-width@^4.2.0",
    "strip-ansi": "^7.0.1",
    "strip-ansi-cjs": "npm:strip-ansi@^6.0.1",
    "wrap-ansi": "^8.1.0",
    "wrap-ansi-cjs": "npm:wrap-ansi@^7.0.0"

大多数开发人员希望在包或 git 或基于文件的 url 的值中看到 semver 版本范围。然而，在这种情况下，有一个特殊的 npm: 前缀语法。是什么意思？

因此，在此拉取请求中提出的更改的情况下，包 string-width-cjs 将解析为版本 ^4.2.0 中的包 string-width。这意味着将有一个 string-width-cjs 的 node_modules 目录条目，但包含 string-width@^4.2.0 的内容以及锁定文件 (package-lock.json) 中的类似行为。

包别名是 npm 包管理器的一项功能，可以合法地用于此处暗示的情况（以帮助 esm 与 cjs 支持）。

话虽如此，包别名可能会被滥用。在一篇可追溯到 2021 年的文章和安全披露中，snyk 大使 nishant jain 演示了如何欺骗官方 npmjs 注册表，根据包别名错误地提供依赖信息，作为依赖关系混淆和供应链安全问题的一部分。

这个拉取请求确实是良性的，并且不存在供应链攻击的风险。 然而，sébastien 对这样的包名产生了怀疑，并发现还有更多值得担心的事情。

在 npm 锁定文件中查找有关恶意模块的可疑行为

当sébastien检查拉取请求时，他运行了一个名为lockfile-lint的工具，该工具有助于验证锁文件，例如package-lock.json或yarn.lock，以确保它们不会被篡改以注入恶意包而不是原始包npm 包.

运行该工具显示以下警告：

npx lockfile-lint --path package-lock.json --allowed-hosts yarn npm --validate-https --validate-package-names

detected resolved url for package with a different name: string-width-cjs
    expected: string-width-cjs
    actual: string-width

detected resolved url for package with a different name: strip-ansi-cjs
    expected: strip-ansi-cjs
    actual: strip-ansi

detected resolved url for package with a different name: wrap-ansi-cjs
    expected: wrap-ansi-cjs
    actual: wrap-ansi

 ✖ error: security issues detected!

免责声明：lockfile-lint 是我在 2019 年开发的一个工具，在我发表文章后，披露了锁定文件的安全问题：为什么 npm 锁定文件可以成为注入恶意模块的安全盲点.

高度警惕：npm 上的流行软件包看起来很相似

鉴于上述 lockfile-lint 结果，sébastien 在 npm 上查找了这些包名称，并惊讶地发现这些包名称确实存在于公共 npm 注册表中：

• https://www.npmjs.com/package/string-width-cjs
• https://www.npmjs.com/package/strip-ansi-cjs
• https://www.npmjs.com/package/wrap-ansi-cjs

sébastien 指出，这些包名称不仅存在于 npm 上，而且它们还具有引起关注的指标：

• 这些包不绑定到任何公共源代码存储库
• 如果检查其内容，这些包中没有任何实际代码。
• 发布这些包的作者身份是匿名的，与任何个人或可识别信息无关。

查看 npm 包 strip-ansi-cjs，没有自述文件，也没有与该包关联的源代码存储库，但有许多合法且流行的包引用了相同的行为。

事实上，对于这个特定的软件包，有许多依赖项（依赖于该软件包的其他软件包）形式的流行信号 - 确切地说，有 529 个依赖项，并且每周下载量也在不断增加，当时总计 7,274 次写作.

查看 strip-ansi-cjs 的代码，可以发现该包中只有一个文件，即包清单 package.json 文件。

那么，为什么一个不做任何事情的包会获得如此多的下载，以及为什么还有那么多其他包依赖它？

我们继续考察这些npm包的作者。

这三个包均归himanshutester002 所有，它们的包均于去年发布，并带有程序化版本号。有些很有趣：

• isaacs-cliui npm 包 - 可能是对 isaac 自己的 cliui 项目分支及其命名空间下的合法 npm 包的误植尝试：@isaacs/cliui.
• azure-sdk-for-net npm 包 - 可能是试图进行依赖混淆活动来攻击同名的私有包。
• link-deep npm 包 - 抢占与 lodash 等实用程序包相关的流行功能

您还可以注意到，用户 himanshutester002 在 npmjs 上的此用户个人资料页面上没有可识别的信息。

我们之前注意到 strip-ansi-cjs npm 软件包有超过 500 个其他软件包使用它，因此，这可能是流行度的积极指标。让我们看看他们：

如果你看一眼，这可能会在这个列表中传递某种合法性，但真的是这样吗？
例如，像 clazz-transformer 或 react-native-multiply 或 gh-monoproject-cli 这样的名称似乎是合法的，但它们是吗？

这是react-native-multiply npm 包页面：

该软件包几乎没有下载，其作者也是一位匿名 npm 用户，没有任何可识别信息。该包重定向到的源 url 存储库是 https://github[.]com/hasandader/react-native-multiply，该存储库不存在，并且 github 用户个人资料看起来非常可疑并且缺乏实际活动。

npm 包内容可能看起来像是有一些实际的源代码，但实际上，它看起来像是为“hello world”应用程序原型生成的代码示例。

你还想知道，如果这个包只是一个乘法库，那么为什么它需要 776 个依赖项来执行以下操作：

import { multiply } from 'react-native-multiply';
const result = await multiply(3, 7);

虽然有些人可能会嘲笑 javascript 滥用依赖项，导致嵌套包的数量达到天文数字，但对于一个项目来说，声明 776 个直接（顶级）依赖项是没有任何意义的。

在所有这些依赖项中，有我们的故事开始时的 3 个可疑的 npm 包：string-width-cjs、strip-ansi-cjs 和 wrap-ansi-cjs：

我们提到 strip-ansi-cjs 依赖项之一名为 clazz-transformer。我们来看看：

让我们解释一下这里发生了什么：

• npm 包名称是 clazz-transformer，但该包的 readme 包页面顶部有一个 class-transformer 标题，这是故意这样做的。
• 同样，源代码存储库是 https://github[.]com/typestack/class-transformer ，它可能是合法的存储库，也可能是假的，但它与“clazz”一词完全没有关联。

github 上关联存储库的typstack/class-transformer 具有 package.json 文件，如下所示：

查看 github 上的 package.json 文件显示没有依赖项声明，但如果我们检查 npmjs 上实际包的源代码，我们会看到此 clazz-transformer 打包时包含的 437 个依赖项。再次，非常方便地捆绑 3 个可疑的 *-cjs 软件包：

对可疑 npm 包发现的进一步思考

在我们得出进一步的结论之前，有必要提及我们在上面观察到的 npm 包的一些特征：

• react native 包似乎源自 create-react-native-library 脚手架工具，该工具还具有默认的乘法函数示例，作为为新项目生成的库存源代码的一部分。
• 包具有可以从 next.js 14 入门样板派生的目录和文件结构以及依赖项，例如使用 npx create-next-app@14 创建的包。

我们在 sonatype 的同行之前已经发现过类似的软件包淹没开源注册表的案例。在这些情况下，最终目标是开发人员用 tea 代币奖励自己，这是一个用于通过开源软件货币化的 web3 平台。

在上述包中找到一些 tea.yaml 文件进一步支持了这一论点，即该活动的部分目的是通过滥用 tea 来挖掘 tea 代币。

今年早些时候，即2024年4月14日，一位茶论坛用户发表了一条评论，进一步支持了对茶滥用的关注：

在给出结论之前，我要真诚地感谢 sébastien lorber 谨慎的维护者心态，并帮助揭示潜在的 npm 供应链攻击的线索。

string-width-cjs 发生了什么？

此时，我非常有信心我可以继续在其余据称依赖于 string-width-cjs 的包中找出漏洞，以找到非常可疑的真实合法性指标。

我的假设是，所有这些依赖包和下载量增加的唯一目的是为 3 个 *-cjs 包创建虚假的合法性，以便在适当的时候，在适当的受害者参与的情况下，这些假包将被安装然后是新的恶意版本。

为了帮助您在使用开源软件时保持安全，我强烈建议采用安全实践，特别是以下后续教育资源：

• 为什么 npm 锁定文件可能成为注入恶意模块的安全盲点
• 10 个 npm 安全最佳实践
• npm 安全：防止供应链攻击

我们是否在他们的不法行为中发现了供应链安全活动，或者这一切都与金钱轨迹有关，因此可以归因于垃圾邮件和滥用 npm 和 github 等公共注册中心来挖掘 tea 代币？

无论如何，请保持警惕。

今天关于《可疑的维护者揭露了 npm 供应链攻击的线索》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！