聚焦源代码安全,网罗国内外最新资讯!
NPM 是 JavaScript 编程语言的程序包管理器,也是广泛使用的 Noje.js 环境的默认配置。该程序包管理器有助于项目管理员自动化安装、升级和配置托管在 npmjs.com 的 npm 注册表数据库上的软件包。
2020年,微软通过 GitHub 收购 NPM 平台,当前预计超过1700万名软件开发人员正在使用该平台,每个月下载20.8亿个程序包。
一名前 GitHub 工程师 Darcy Clarke 提出了该 manifest 混淆问题,他在文章中解释称,尽管 GitHub 至少在2022年11月就知晓该问题,但几乎未采取任何措施解决关联风险。
由于该NPM 注册表中包含大量无需额外开发工作就能够扩展应用程序特性的程序包,因此立即引起开发人员的关注。然而,这种巨大的热度使其成为威胁行动者的主要目标,被用于分发恶意包接管开发人员的计算机、窃取凭据甚至部署勒索软件。
当程序包在 npm 注册表上展示的 maniefest 信息,与安装该程序包时使用的发布的 npm 包tarball 中的实际的 “package.json” 文件不一致时,就会发生Manifest 混淆。
发布程序包和 package.json 时提交给 NPM 的 manifest 数据中都包含和程序包名称、版本和其它元数据相关的信息,如部署、构建依赖中所使用的脚本等。这两种数据被单独提交给 npm 注册表,而npm平台并未验证它们是否匹配,因此数据可能不同,而如果不检查内容,则无人知晓这一点。这就使得威胁行动者能够修改通过新包提交的 manifest 数据,删除依赖和脚本,使它们不会出现在 NPM 注册表中。然而,这些脚本和依赖仍然存在于 package.json 文件中,而且会在安装该程序包时被执行。
该 “manifest 混淆”如下图,显示 Clarke 的 PoC 程序包上并没有列出任何依赖,尽管package.json 中列出了相关依赖。
“manifest 混淆”不一致所引发的风险包括缓存投毒、安装未知依赖、执行未知脚本以及降级攻击。
Socket 公司的首席执行官 Feross Aboukhadijeh 表示,“而且不仅仅是隐藏的依赖。”他表示他们的工具并不受影响,“Manifest 混淆还可使攻击者包含隐藏脚本。这些隐藏的脚本和依赖不会出现在 npm 网站或多数安全工具中,尽管会被 npm CLI 安装。”
遗憾的是,npm 设备和所有主要的程序包管理器包括 npm@6、npm@9、yarn@1和pnpm@7均受影响。由于依赖、版本号甚至是程序包名称均可能是不准确的,因此导致 NPM 注册表缺乏信任。
开发人员应亲自阅读package.json来判断版本号、将安装的依赖以及将要执行的脚本。
Clarke 表示,GitHub至少在2022年就知晓这个 manifest 混淆问题,npm CLI 的 GitHub 仓库就 node-canvas 包提交了一个漏洞报告,似乎也证实了这一点。
2023年3月9日,Clarke 在 HackerOne 平台上提交了一份内含相关问题示例的报告。2023年3月21日,GitHub 关闭该工单并表示内部正在处理该问题。然而,GitHub 仍未缓解该风险且并未与 npm 社区沟通交流。
Clarke 提到,鉴于 npm 的庞大体量以及这一不安全实践已存在多年,因此修复并非易事。在 GitHub 提出解决方案之前,Clarke 建议所有的包作者和维护人员删除对 manifest 数据的依赖,并将所有元数据与不太容易被操控的 package.json 文件中的名称和版本剥离。另外一种防御措施是,在程序包数据库和npm 客户端之间使用注册表代理,执行额外检查和炎症,确保 manifest 数据和该程序包 tarball 中信息之间的一致性。
GitHub 尚未就此事置评。
题图:Pixabay License
本文由奇安信编译,不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。
奇安信代码卫士 (codesafe)
国内首个专注于软件开发安全的产品线。
觉得不错,就点个 “在看” 或 "赞” 吧~
原文始发于微信公众号(代码卫士):NPM生态系统易受 Manifest 混淆攻击
- 左青龙
- 微信扫一扫
- 右白虎
- 微信扫一扫
评论