又一起 npm 供应链攻击:'is' 包被入侵

npm "is" 包 3.3.1 和 5.0.0 版本遭入侵——每周数百万下载量的关键工具沦为钓鱼攻击受害者

持续进行的 npm 供应链攻击又添新受害者。广受欢迎的 "is" 包作为 JavaScript 生态中的基础类型检查工具,在攻击者成功钓鱼并劫持一位老维护者的账户后遭到入侵。此事件代表了针对 eslint-config-prettier 及多个其他广泛使用包的钓鱼活动的又一次升级。

攻击时间线

2025 年 7 月 19 日,"is" 包的恶意版本被发布到 npm,其中包括 3.3.1 和 5.0.0 版本。此次攻击是针对 npm 维护者持续进行的钓鱼活动的一部分。然而攻击手段尤其狡猾:威胁参与者首先通过钓鱼攻击破坏了旧维护者的账户,然后操纵 npm 的所有权系统来获取控制权。

Jordan Harband,一位掌控数百个 npm 包的知名 JavaScript 维护者,透露了他是如何无意中陷入此次攻击的。

Jordan Harband 讲述的攻击经过

此次入侵的细节尤其令人担忧。Jordan Harband 在 Bluesky 上分享了他的经历:

攻击通过复杂的欺骗手段展开:

  1. 原维护者的 npm 账户被劫持(可能通过持续进行的钓鱼活动)
  2. 该维护者从 npm 上的 "is" 包中被移除
  3. 被劫持账户的所有者通过电子邮件联系当前维护者团队,声称 npm 因未启用双因素认证而将其移除
  4. 旧维护者被重新添加到账户中
  5. 次日早晨,攻击者利用恢复的访问权限发布了恶意版本 3.3.1 和 5.0.0

正如维护者在后续帖子中所述,恶意代码在六小时内未被察觉——比平时更长。攻击者先后发布了 3.3.1 版本,随后又发布了 5.0.0 版本,可能使用了预先存在的会话。

这种多阶段攻击巧妙地利用了维护者之间的信任以及 npm 所有权系统中缺乏适当通知的漏洞。

供应链安全中的人为因素

此事件凸显了开源维护中一个关键漏洞:人为因素。攻击者无需破坏技术系统或寻找零日漏洞。相反,他们:

  1. 使用钓鱼攻击劫持了原维护者的 npm 账户
  2. 编造了关于 npm 因未启用双因素认证而移除账户的可信故事
  3. 利用维护者之间的信任来重新获取包访问权限

此次攻击的复杂性表明:

  • 攻击者深入了解 npm 的治理模式和维护者关系
  • 利用了对 npm 通知系统的合理不满
  • 社会工程即使对经验丰富的维护者也卓有成效
  • 个人事务(如在游泳比赛中做志愿者)可能延迟攻击的发现

开发者立即行动

如果您在依赖项中有 "is" 包:

立即检查您的包版本

  1. 受影响版本:3.3.1 和 5.0.0
  2. 运行 npm ls is 检查已安装版本

如已受入侵则进行修复

  1. 完全移除 node_modules
  2. 清除 npm 缓存:npm cache clean --force
  3. 更新 package-lock.json 以排除恶意版本
  4. 使用安全版本(3.3.0 或 3.3.2+)重新安装依赖

审计您的环境

  1. 检查是否有未经授权的网络连接
  2. 审查浏览器安全设置(Chrome 用户应检查安全警告)
  3. 轮换所有 npm 令牌和凭据
  4. 如怀疑已被入侵,考虑完整系统重装

适用于 StepSecurity 企业客户

以下步骤仅适用于 StepSecurity 企业客户。如果您不是现有企业客户,可以安装 StepSecurity GitHub App 开始我们的 14 天免费试用,以完成以下恢复步骤。

发现升级到受入侵 npm 包的拉取请求

我们添加了一个新的控制项,专门用于检测升级到这些受入侵包的拉取请求。您可以在 StepSecurity 仪表板上找到新的控制项。

使用 StepSecurity Artifact Monitor 检测授权管道外的软件发布

StepSecurity Artifact Monitor 通过持续监控包注册表中的工件,提供对未授权包发布的实时检测。该工具会通过检测 9.1.1 版本是在项目授权 CI/CD 管道外发布的来标记 eslint-config-prettier 事件。该监控器追踪发布模式、验证来源,并在包通过异常渠道或从未知位置发布时向团队发出警报。通过实施 Artifact Monitor,组织可以在数分钟而非数小时或数天内发现供应链入侵,显著减少暴露于恶意包的时间窗口。

了解如何在您的安全工作中实施 Artifact Monitor,请访问 StepSecurity Artifact Monitor

使用 StepSecurity Harden-Runner 检测 CI/CD 中被入侵的依赖项

StepSecurity Harden-Runner 为您的 GitHub Actions 工作流添加了运行时安全监控,提供对 CI/CD 运行期间网络调用、文件系统更改和进程执行的可见性。在 eslint-config-prettier 入侵等情况下,Harden-Runner 会检测并警告可疑行为,例如到恶意域的意外网络连接或在构建过程中未经授权的文件修改。该工具为工作流中的所有活动创建审计跟踪,在调查潜在安全事件时实现快速取证分析。通过使用运行时监控强化您的 CI/CD 管道,您可以防止被入侵的依赖项在构建环境中执行恶意代码。以下截图显示了 Harden-Runner 如何检测到 tj-actions 供应链事件

按照此指南在您的工作流中实施 Harden-Runner

更广泛的影响

"is" 包不仅仅是一个 npm 模块——它是整个 JavaScript 生态中使用的基础工具。它的入侵可能影响数千个项目和数百万次安装。攻击表明,针对基础包的定向攻击可以在现代软件供应链中产生巨大的爆炸半径效应。

展望未来

随着这些攻击持续演变,JavaScript 社区必须调整其安全实践。攻击者正在利用使开源协作成为可能的基于信任的关系。

npm 生态系统需要:

  • 为所有权变更提供更好的通知系统
  • 增强维护者添加的验证流程
  • 改进包发布的异常检测
  • 加强默认安全配置

在这些系统性改进实施之前,每个使用 npm 包的开发者和组织必须保持警惕,并实施纵深防御策略来保护其软件供应链。

欲获取有关此事件及相关供应链安全事件的持续更新,请关注我们的博客。​