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

当依赖于来自非商业实体的第三方包时,总是存在缺乏支持的风险,特别是涉及到过时的包和版本时。如果包停止维护,就没有人会实现我们可能需要的新特性或修复新发现的问题安全漏洞。考虑,例如,cve - 2019 - 17571。一个严重的远程代码漏洞,在Log4j 1中从未修复。因为它不再被支持,并且只在Log4j 2.x中得到了修复。
在这篇文章中,我们将介绍一个更严重的缺乏维护的情况,其中一个分配给项目的用户帐户(在我们的例子中,是npm包)由于帐户的电子邮件域过期而变得“可劫持”。无论如何,这并不是一种新的攻击技术,但它似乎是第一次就npm注册表上的这种攻击进行大规模的公开讨论。攻击者可以以维护者的身份访问项目,从而发布包含恶意代码的npm包的新版本,并执行软件供应链攻击。
在下面这条推文发布后,我们开始关注这个问题,它声称攻击被用来劫持一个非常多产的npm包-
1.购买过期的NPM维护电子邮件域。
2.重新创建维护人员的邮件
3.接管包
4.提交合法的安全补丁,包括包。Json版本碰撞到恶意的依赖你推
5.享受统治世界。——兰斯·r·维克(@ lrvick@mastodon.social) (@lrvick)2022年5月9日
我们开始在npm包存储库的上下文中找出这种软件供应链攻击到底是如何工作的,它有多常见,到底谁是脆弱的,以及如何防御它。
域接管攻击是如何工作的?
在讨论攻击之前,让我们先讨论一下npm注册表中的相关构建块-
- 每个npmjs.com用户都注册了一个相关的电子邮件地址
{"范围":{“类型”:“用户”、“名称”:“srmish-jfrog”……“电子邮件”:“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下载(据NPM报道,每周下载量约67万)

有必要提到的是,一个域名过期的维护人员不会被劫持吗如果为该维护帐户启用了双因素身份验证(2FA)。具体来说,在实施劫持并获得临时登录密码后,攻击者将不得不输入2FA令牌,而他/她通常不拥有这个令牌。
由于检测一个特定的npm用户是否启用了2FA似乎是不可能的(无论实际值如何,用户配置文件中的“tfa”属性总是设置为“null”),因此脆弱包的真实数量是上述的一个子集。
{"scope": {"type": "user", "name": "srmish-jfrog", "parent": {"tfa": null, //无论tfa是否开启,始终为空
还要注意,包维护人员可以选择加入来要求这样做任何发布新版本包的用户都必须启用2FA。
为了保护相关的npm包维护人员,我们不打算公布潜在易受攻击包的列表,我们已经通过私人邮件通知了他们。
npm注册表中的哪些安全措施有助于防止域接管攻击?
幸运的是,npm维护者已经实现了一些针对这类软件供应链攻击的防御机制。
强制2足总
双因素身份验证(2FA)长期以来一直是勤奋的包维护人员可选的安全缓解方法。
如前所述,任何启用2FA的维护人员都不应该容易受到这种攻击,因为即使在获得临时登录密码后,攻击者也必须输入2FA令牌。
关键是,自2021年12月以来,前100个npm包的维护者(按依赖者)强制启用2FA。除此之外,npm维护者还在寻找对前500个npm包执行2FA(受抚养人)到2022年第二季度结束。
除了以上几点,npm维护者推出了更多的2FA选项,以鼓励更多的维护者启用2FA -
非常高兴npm终于支持网络认证了,这为我们带来了物理安全密钥和生物识别作为2FA选项https://t.co/4DEMVDt3Mi
- sMyle (@MylesBorins)2022年5月10日
尽管这些都是很好的措施,但必须注意的是,一个流行的包仍然可能通过它的依赖被劫持。例如,如果一个受欢迎的包(强制2FA)依赖于一个不太受欢迎的包,它可以被劫持,并且不具有强制2FA,那么劫持不太受欢迎的包可能会导致受欢迎的包也受到损害。这还取决于流行的包维护程序在更新其依赖项之前执行的检查类型。
其他机制
在最初的Twitter帖子中,有人提到npm维护者实际上正在实施更多的帐户接管防御
刚刚和他聊得很开心@MylesBorins在@npmjs安全。
他们正在积极实施帐户接管防御,至少对签名和信任网等更大的解决方案有一些兴趣。
我会努力与他们合作,而不是反对他们前进。
——兰斯·r·维克(@ lrvick@mastodon.social) (@lrvick)2022年5月11日,
这些机制可能会阻止域接管攻击,甚至对于禁用了2FA的维护人员也是如此。
如何防止通过域接管的npm包劫持?
尽管有缓解因素,但似乎一些npm包可能会受到这次攻击的影响。
对npm包维护人员的指导
我们鼓励npm包维护者检查他们每个包的完整维护者列表。如果您怀疑您的特定包的任何帐户可能不需要或易受域过期影响,我们建议执行以下操作之一:
- 从维护者列表中删除该帐户
- 为帐户启用2FA (Two-Factor authentication)认证功能
- 将帐户的电子邮件地址切换到一个更持久的提供商
作为一种谨慎的措施,我们向所有维护一个包的npm用户发送了一封警告邮件,该包的另一个维护者的域已经过期。
指导开发人员
由于npm恶意包进入你的软件的潜在影响很大,我们强烈建议开发人员检查他们所有的依赖项,以确保他们没有使用易受域接管攻击的包。
虽然我们不建议手动这样做,但这可以通过使用“npm show”命令来实现,以获取包维护程序的列表(例如lodash包),
$ npm show lodash lodash@4.17.21 | MIT | deps: none | versions: 114…维护者:—mathias - jdalton - bnjmnt4n …
然后查询每个邮件域(qiwi。be、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。