在过去的几年里，攻击者通过接管维护者的账户来劫持流行的npm包。在Nautilus团队的研究中，我们发现npm平台有两个与双因素认证(2FA)相关的漏洞。攻击者可以利用这些漏洞针对npm包进行帐户接管攻击。目前，研究人员已将这些发现报告给了npm团队(GitHub)，后者迅速修复了底层的安全漏洞。

不过在排名前35位的npm包中，有32%账户仍然面临着被接管的风险。

npm和JavaScript

在过去的一年里，65%的开发人员使用过JavaScript语言。对于那些不熟悉npm的人来说，它代表Node Package Manager。基本上，它是Node JavaScript平台的包管理器。NPM也是世界上最大的软件注册中心，数以百万计的开发者使用它发布和分享他们的代码。

2021年的堆栈溢出

现在，开发人员在整个软件开发过程中使用大量的第三方开源包，这使他们处于软件供应链攻击的风险中。流行的包管理器(如npm)及其用户通常是目标。通常，攻击者会将恶意代码直接嵌入到良性包或其直接或过渡依赖项中。

一个例子是UA-Parser-JS，这是一个每周下载数百万次的 npm 包，在受到加密挖掘和密码泄露恶意软件的攻击后迅速更新。最近的一份报告显示，2021年软件供应链攻击增加了6倍。

攻击者可以通过几种方式访问所需的包。一种方法是获取包维护者的凭证。

2017年安全研究人员就已经能够直接访问14%的npm包(或间接访问54%的包)。他们使用暴力破解或重用在其他攻击中发现的密码，导致npm用户大规模重置密码。

由于npm的结构，被劫持或恶意包的影响更大。NPM鼓励创建小的包来解决单个问题。这将导致大量较小的包，每个包都依赖于其他几个包。

由于攻击者已经掌握了泄漏的密码，因此可以访问更有价值的包。

这是一个关于express的依赖关系图，它是npm上最受欢迎的10个包之一，截止到2022年4月，它每周平均下载量为2500万次。

攻击者如果获得了对express的直接或传递依赖项的访问权，就有可能破坏整个包。不过，实际情况要复杂得多。

2019年的一项研究发现，软件包平均隐含信任79个第三方软件包和39个维护者。此外，受欢迎的包通常会影响超过10万个其他包，这使它们成为攻击的主要目标。

npm在安全方面的改进

npm的安全性也在不断提高。从2022年2月开始，npm要求所有依赖项排名前100的npm包的维护者都使用2FA。

双因素身份验证还计划用于高影响的包，即每周下载超过100万次或依赖项超过500的包。

对于维护者来说，2FA非常重要，因为它可以立即降低与被盗用密码相关的风险。如果一个密码被泄露，被猜测，甚至是网络钓鱼，这已经不足以让攻击者访问。没有第二个因素没有被确认，密码是无用的。

此外，npm还启动了增强的登录验证，因为它需要额外的验证才能让你登录。如果你没有启用2FA，一次性密码将被发送到与你的帐户相关的电子邮件地址。

但设置 2FA 始终是一种更强的做法，因为仅使用一次性密码是不够的。如果你的 npm 密码被泄露，很可能你的私人电子邮件帐户的密码也被泄露了。在许多情况下，它将是相同的密码，这使攻击者可以绕过发送到你的电子邮件的一次性密码。从安全角度来看，这些改进都是好消息。在软件供应链中，没有2FA服务的维护者，比如软件包托管、发布新版本、或者登录npm账户，往往是安全薄弱环节。

然而，俗话说:“链条的强度取决于它最薄弱的环节。”还需要对直接和可传递包依赖的维护者实施相同的要求，以确保包安全性。

npm信息泄露：2FA枚举

为了进行更深入地研究，我们试图找出流行的npm包(其维护者被迫启用了2FA)仍然面临着帐户被接管的风险的数量，因为它们的直接和可传递依赖的维护者没有使用2FA。

我们的第一个挑战是确定npm用户是否启用或禁用了2FA。毕竟，这样的信息不应该对每个用户都开放。

事实证明，有一种简单的方法可以发现它。作为一个包的创建者，任何npm用户都可以被添加为一个维护者。

因此，我们可以：

创建和发布 npm 包；

浏览到包设置页面：https://www.npmjs.com/package/<  packlage_name >/access

添加你希望枚举 2FA 的 npm 用户作为维护者。例如，在尝试使用泄露的密码登录他们的帐户之前；

用户 2FA 状态将显示在维护者窗口中：

这个功能是为了保护开发人员，并在将用户添加为包的维护者时显示用户的安全性。但它也可能被滥用。

2022年2月，我们在HackerOne上通过GitHub的漏洞赏金项目向npm工作人员报告了这些问题，并得到了以下答复:

“这是一个之前发现的问题，正在内部跟踪处理。我们正在积极开展修复工作”。

在2022年3月，补丁被推出，npm不再显示维护者的2FA状态。

NPM信息披露:‘enforced tfa’枚举

为了方便研究，我们找到了一种方法来确定特定的维护者是否必须启用2FA，以及组织是否要求其员工使用2FA。

任何未经认证的用户都可以查询' enforced_tfa '是否在其他npm用户或组织上启用，以及确定该用户是否为工作人员等。

我们惊讶地发现，每个用户或组织的npm配置文件都包含了此信息!

具体可分3个步骤:

向 https://www.npmjs.com/~<  username > 或https://www.npmjs.com/org/<  scope_name >

查看请求的响应；

在 window.context json 中提取“enforced_tfa”和“isStaff”的值；

例如，我们可以看到Facebook (fb user)要求npm启用双因素身份验证。

我们通过 HackerOne 上 GitHub 的漏洞赏金计划向 npm 工作人员报告了以下漏洞。目前该漏洞已得到验证和修复。

‘enforced tfa’ 枚举的信息披露时间表

14-02-2022：该漏洞已报告给 GitHub 在 HackerOne 的漏洞赏金计划；

14-02-2022：从 GitHub 收到他们正在调查该漏洞的初步回复。

17-02-2022：GitHub 安全团队确认的漏洞。

25-03-2022：在 npmjs.com 上修复了漏洞。

技术细节

现在我们有了一种方法来确定用户是否启用了 2FA，我们可以计算存在被包依赖项的维护者接管帐户风险的顶级 npm 包的百分比（如果他们没有启用 2FA）。

当满足以下两个条件时，用户的设备就可能处于被攻击的风险中：

2FA 未强制执行；

旧密码/当前密码已泄露；

为了确定这一点，我们将使用haveibeenpwned API和' enforced_tfa '方法来枚举npm用户的强制2FA状态。

现在，我们将编写一个简短的Python脚本来总结这个过程。为了方便讲解，我们将在2022年2月的前35个npm包上运行这个脚本(显示在npmjs.com上)，然后我们将检查依赖维护者的强制2FA状态和密码泄漏状态。

值得强调的是，如果从 enforced_2fa 变量返回 false 值，并不一定意味着用户没有启用 2FA。但是，在本研究中，我们会将这个用户视为尚未启用 2FA 的维护者，以便我们评估潜在风险。

另外，如果包依赖于另一个包的特定版本，攻击者将无法影响其依赖关系。但在许多情况下，这可能会导致其他漏洞，例如未修复的易受攻击的软件包。

此外，软件包通常依赖于使用~/^符号的版本，这些符号表示补丁和次要版本。这使攻击者有机会推送带有补丁或次要版本的恶意包，这些补丁或次要版本会直接影响依赖包。

此外，即使一个包需要另一个包的特定版本，控制其中一个维护者帐户的攻击者也可以将包标记为易受攻击，从而将下游包推送到攻击者的恶意包版本。

在本文中，如果至少有一条路径允许依赖项使用恶意代码更新根包，我们会将包标记为处于风险中。在研究过程中，我们发现在大多数情况下有很多种方法可以做到这一点。

下面的数据是在执行上面的代码之后获得的前35个流行的npm包的数据（具体统计数据请参见附录）。

统计分析

根据我们的分析，前 35 个 npm 包中的 32% 仍存在被依赖项所有者接管帐户的风险，这使得攻击者可以滥用根包。

同样重要的是要注意，当涉及到 devDependencies 时，结果可能很严重。

实际上，devDependencies 的结果表明泄漏概率为 72%。这意味着这些 devDependencies 的维护者没有启用双重身份验证，并且根包不使用这些依赖项的特定版本，也就是说，根包使用~/^符号。

此外，有时候在devDependencies中需要的包是相对可以忽略的。与生产依赖项（ production dependency）相比，devDependencies的平均下载次数并不高(低于100万次)，这并不需要它们的维护者通过npm启用2FA。

在下面的攻击向量中，攻击者可以直接访问根包维护者的工作空间。

此外，结果表明，当特定流行包的间接维护者多于直接维护者时，该包就处于危险之中。在某些情况下，这个比率是body-parser包的几十倍，甚至是125倍。

包含许多维护人员的包提供了许多执行帐户接管和社会工程攻击的机会。对于直接依赖和间接依赖以及devDependencies包来说也是如此。

ms包的风险

现在让我们详细了解一下ms包。这个包将各种时间格式转换为毫秒，并且相对较小。截至2022年4月，这个软件包每周的下载量为1.64亿次，其中包含约3200个依赖软件包。

这个包的主要问题是有大约130人的维护者。

如果一个包不依赖于特定版本的 ms，它可能会面临严重的风险。就像 humanize-ms 包（每周下载 600 万次）一样，这取决于 ms ^2.0.0 版本。

大量的维护者意味着，只有攻击者破坏了其中一个维护者的权限，则它就可以拥有全部的访问权限，潜藏的危害更大。目前，大约 66% 的 ms 包维护者尚未强制执行 2FA，并且他们的密码变体先前已被泄露。

避免间接维护者帐户接管风险的另一种方法是“固定”依赖项。例如，调试包的 78% 的间接维护者处于危险之中。但是，无法影响根包（调试包），因为它使用 package.json 文件中依赖项的绝对版本。

一旦 npm 对下载量超过 100 万的软件包的所有维护者强制执行 2FA，上述风险将得到补救。

总结

近年来，开源项目，尤其是npm，已经提高了它们的安全性。然而，攻击者也在改进他们的方法和工具。

与防御者不同，攻击者只需要一次成功(在我们的例子中是一个被破坏的包)就可以启动攻击杀死链。根据我们的研究，拥有大量维护者的npm包被滥用的风险更高。开发人员需要考虑到这一点，至少在使用依赖项时锁定它们。作为开发人员，我们需要最大限度地减少攻击面，并使攻击者的帐户接管更具挑战性。否则，结果可能会损害整个社区。最后，我们强烈鼓励那些致力于开源和创建包的开发者在他们的所有帐户上启用2FA，以保证他们的社区安全。

附录

本文翻译自：https://blog.aquasec.com/npm-supply-chain-attack如若转载，请注明原文地址