通过域名接管的Npm包劫持:这种“新”攻击有多严重?
JFrog安全研究团队对这种npm软件供应链攻击进行了数据驱动分析,并为npm包维护者和开发人员提供了指导

当依赖于来自非商业实体的第三方软件包时,总是存在缺乏支持的风险,特别是当涉及到过时的软件包和版本时。如果包停止维护,没有人会实现我们可能需要的新功能或修复新发现的功能安全漏洞。例如,考虑一下,cve - 2019 - 17571。一个严重的远程代码漏洞,在Log4j 1中从未修复。因为它不再被支持,并且只在Log4j 2.x中修复。
在这篇文章中,我们将介绍一个更严重的缺乏维护的情况,其中一个分配给项目的用户帐户(在我们的例子中是npm包)由于帐户的电子邮件域过期而变得“可劫持”。无论如何,这并不是一种新的攻击技术,但这似乎是第一次针对npm注册表的这种攻击进行大规模的公开讨论。以维护者的身份访问项目后,攻击者可以发布包含恶意代码的新版本npm包,并对其进行攻击软件供应链攻击。
在以下推文发布后,我们开始关注这个问题,该推文声称攻击被用来劫持一个极其多产的npm包-
1.购买过期的NPM维护者电子邮件域名。
2.重新创建维护者邮件
3.接管包裹
4.提交包含包的合法安全补丁。Json版本碰撞到您推送的恶意依赖
5.享受统治世界的乐趣。- Lance R. Vick (@ lrvick@mastodon.social) (@lrvick)2022年5月9日
在npm包存储库的背景下,我们开始研究这种软件供应链攻击是如何工作的,它有多常见,谁是脆弱的,以及如何防御它。
域名接管攻击是如何工作的?
在讨论攻击之前,让我们先讨论一下npm注册表中的相关构建块
- 每个npmjs.com用户都注册了一个相关的电子邮件地址
{"范围":{“类型”:“用户”、“名称”:“srmish-jfrog”……"email": "foo@www.si-fil.com"… - 一个npm包可以有多个维护人员(例如,允许上传新版本软件包的用户)
…“维护者”:[{“名称”:“srmish-jfrog”,“电子邮件”:“foo@www.si-fil.com”},{“名称”:“my-old-user”,“电子邮件”:“foo@somedomain.sh " }, ], ... - npm的“忘记我的密码”的工作原理是向用户的注册电子邮件地址发送一个临时密码。目前,该机制除了拥有电子邮件地址外,不需要其他知识。

记住这一点——攻击依赖于一个包的维护者在一个自定义域(例如,不是@gmail.com)拥有一个相关的电子邮件地址。哪个域名已经过期了(例如上图中的somedomain.sh)。这意味着任何人都可以通过域名注册商购买该域名:

然后把所有的邮件发给foo@somedomain.sh到达攻击者的电子邮件地址。
这包括“忘记我的密码”的电子邮件,带有npm的临时密码,这将允许攻击者劫持my-old-user帐户和随后它维护的任何NPM包,通过上传一个新的恶意版本的包!
因此,在不到50美元的预算下,不需要任何重大努力,理论上可以用一个流行的软件包快速感染数万台主机,如果长期针对多个软件包,甚至可以感染更多主机。
有多少npm包可能容易受到这种劫持攻击?
在看到建议的攻击向量后,我们开始使用NPM api来检索相关数据,以了解NPM中有多少软件包实际上是易受攻击的。
我们的结果如下
- 3210独特包装在其最新发布的版本中,至少有一个拥有可购买域的维护者
- 这约占所有npm包的0.16%(由modulecounts)
- 其中,393个包由多个维护者管理,2817个包由单个维护者管理
- 这些只是直接(潜在)脆弱包。这些数字不包括依赖于某个潜在易受攻击软件包的软件包
- 甚至还有更多的包裹过期的域名,目前无法购买,因为该域名目前正在等待删除或处于修复期
- 900年维护者是否发现有一个可购买的电子邮件域
- 这大约占所有注册npm维护者的0.17%
- 最容易受到此攻击的软件包的总下载计数为~ 31 m下载(每周下载量约为67万)

重要的是要提到一个域名过期的维护者不会被劫持吗如果为该维护帐户启用了双因素身份验证(2FA)。具体来说,在执行劫持并获得临时登录密码后,攻击者将不得不输入他/她通常不拥有的2FA令牌。
由于似乎无法检测到特定的npm用户是否启用了2FA(用户配置文件中的“tfa”属性总是被设置为“null”,而不管实际值是多少),因此易受攻击的包的实际数量是上述的一个子集。
{"scope": {"type": "user", "name": "srmish-jfrog", "parent": {"tfa": null, //无论是否启用tfa,始终为null
还要注意的是,包维护者可以选择加入要求这样做任何发布新版本包的用户都必须启用2FA。
为了保护相关的npm包维护者,我们不打算发布潜在易受攻击包的列表,我们已经通过私人电子邮件提醒了他们。
npm注册表中的哪些安全措施有助于防止域接管攻击?
幸运的是,npm维护者已经实现了一些针对这种类型的软件供应链攻击的防御机制。
强制2足总
长期以来,双因素身份验证(2FA)一直是勤奋的包维护人员可选的安全缓解措施。
如前所述,任何启用了2FA的维护者都不应该受到这种攻击,因为即使在获得临时登录密码后,攻击者也必须输入2FA令牌。
关键的是,自2021年12月以来,npm包的前100名维护者(按依赖项)强制启用2FA。除此之外,npm维护者还希望对排名前500的npm包实施2FA(按家属计算)到2022年第二季度末。
除了上述几点,npm维护者还推出了更多的2FA选项,以鼓励更多的维护者启用2FA -
非常高兴终于在npm上支持WebAuthn,为我们带来物理安全密钥和生物识别作为2FA选项https://t.co/4DEMVDt3Mi
——sMyle (@MylesBorins)2022年5月10日
尽管这些都是很好的措施,但必须注意的是,一个受欢迎的软件包仍然可能通过其依赖项被劫持。例如,如果一个受欢迎的软件包(强制2FA)依赖于一个不太受欢迎的软件包,该软件包可以被劫持,并且没有强制2FA,那么劫持不太受欢迎的软件包可能也会导致受欢迎的软件包受到损害。这还取决于流行的包维护者在更新依赖项之前执行的检查类型。
其他机制
在最初的Twitter帖子中,有人提到npm维护者实际上正在实现更多的账户接管防御
刚刚和。聊得很开心@MylesBorins在@npmjs安全。
他们正在积极实施账户接管防御,至少对签名和信任网络等更大的解决方案有一些兴趣。
我会试着和他们一起对抗。
- Lance R. Vick (@ lrvick@mastodon.social) (@lrvick)2022年5月11日
这些机制可以阻止域接管攻击,即使对于禁用2FA的维护者也是如此。
如何保护从npm包劫持通过域名接管?
尽管存在缓解因素,但似乎有些npm包可能会受到这种攻击的影响。
npm包维护者指南
我们鼓励npm包维护者查看每个包的完整维护者列表。如果您怀疑您的特定包的任何帐户可能不需要或容易受到域过期的影响,我们建议执行以下操作之一:
- 从维护者列表中删除该帐户
- 为帐户启用双因素身份验证(2FA)
- 将帐户的电子邮件地址切换到更永久的提供商
作为一项警告措施,我们向所有维护一个包的npm用户发送了一封警告邮件,该包的额外维护者的域名已经过期。
开发者指南
由于npm恶意包进入您的软件的潜在影响很大,我们强烈建议开发人员检查他们所有的依赖项,以确保他们没有使用易受域接管攻击的包。
虽然我们不建议手动执行此操作,但可以通过使用" npm show "命令来获取包维护者列表(例如lodash包),
$ npm show lodash lodash@4.17.21 | MIT | deps: none | versions: 114…维护者:- mathias - jdalton - bnjmnt4n …
然后查询每个邮件域(qiwi)。在上面的例子中,如gmail.com和dev.ofcr.se)针对WHOIS提供商(如whois.com)或域名注册商(如namecheap.com).
如果WHOIS提供商或域名注册商显示该域名已过期或可购买,您应联系软件包维护人员或考虑使用维护更完善的软件包。
如前所述,拥有一个过期的域并不能100%保证维护者和/或包可以被劫持,但由于某些情况是脆弱的,这是一个应该由包维护者修复的缺陷。
不建议使用这种手动过程,因为它冗长且容易出错。例如,下面列出的电子邮件维护人员并不总是与维护者的NPM帐户相关联的最新电子邮件地址。
为了更容易地检测这个潜在的漏洞,我们编写了一个执行此检查的自动化工具。
JFrog安全OSS工具- npm_domain_check -自动检测域接管
为了帮助加快检查对域名接管攻击的易感性的过程,我们正在发布npm_domain_check-一个OSS安全工具,自动确定本地包(或其任何依赖项)是否有一个域名过期的维护者。
该工具将包的路径作为输入。NPM包的Json文件,并列举该包的所有直接和间接依赖项。对于每个依赖项,该工具找到它的维护者并验证他们的电子邮件域。如果域名可供注册或即将过期,则会显示警告。

结论
对于有兴趣创建僵尸网络的攻击者来说,目前看来,这种npm包劫持方法很容易被利用,并且可能以自动化的方式被利用。
对于对目标攻击感兴趣的攻击者,或者对非常高价值的目标(非常受欢迎的包)感兴趣的攻击者,由于npm的强制2FA强制实施和其他帐户接管防御,这种攻击似乎不太可行。
我们鼓励所有npm包所有者确保他们的维护者列表是最新的,并且不包含任何不活跃的维护者,这些维护者可能会在将来成为问题,例如,如果维护者的域过期了。
与JFrog安全研究保持同步
关注JFrog安全研究团队的最新发现和技术更新安全研究博客文章并在推特上@JFrogSecurity。
