ChainDrop 把一次 npm 软件包失陷事件，变成了对开发者机器安全的一记警示。
在攻击者控制与 Keyv 缓存库关联的 GitHub 账户后，这场能够自我传播的恶意活动共投毒 444 个软件包，并发布超过 1300 个恶意版本。受影响软件包的月安装量合计超过 20 亿次。
Abby Kearns 在与 Cyber Security News（CSN）分享的报告中指出，这次攻击最特殊的地方在于，攻击者刻意绕过了供应链控制紧盯的安装环节。微软将这一活动命名为 ChainDrop，其他研究人员则将其追踪为 Mini Shai-Hulud，因为它的行为模式与近期的 Mini Shai-Hulud 活动表现一致。
初始入侵入口目前仍未公开。但事件已经说明，一个被入侵的维护者账户如何把可信发布（Trusted Publishing）、自动化工作流和开发者工具变成恶意分发渠道。它也抛出一个值得追问的问题：工程团队是否只把仓库当源代码检查，却没有意识到仓库内容可以指示本地工具执行操作？
01 ChainDrop npm 蠕虫
攻击始于 8 月 4 日，Keyv 背后的 GitHub 账户以及 cacheable、flat-cache、file-entry-cache 等软件包同时失陷。攻击者利用窃取的凭据发布被篡改版本，随后继续收集发布权限以扩大感染范围。跟踪最新主版本的项目风险最突出，而锁定旧主版本的项目相对安全。
这些版本之所以看起来可信，是因为它们附带了有效的来源证明（provenance attestations）。
从被盗账户出发的四个步骤
这些版本都是通过配置为 npm 可信发布者的GitHub Actions 工作流发布的，因此记录显示发布行为来自一个已获批准的身份。真正的问题出在上游：恶意源代码在工作流运行之前就已进入仓库。今年早些时候披露的 GitHub Actions 工作流弱点也验证了这一点。
这一区别非常关键：来源证明能够确认构建来源，却无法保证生成该构建的计算机、账户或仓库本身是干净的。在本案中，签名没有被伪造，发布流水线也没有被攻破。攻击者只是滥用了生态系统中本就设计为可信任的访问机制。
对维护者来说，处置过程既复杂又耗时。Keyv 维护者清空了受影响机器，停用 GitHub Actions 和可信发布，撤回被入侵版本，删除恶意分支和标签，并重置了受影响分支。团队也应立即撤销并轮换暴露的凭据，审查工作流权限，并从已知干净状态重建受影响的开发环境或 CI 环境。
02 仓库文件成为执行路径
ChainDrop 还在最多 50 个分支的可访问仓库中放置了两个配置文件：一个用于注册 Claude Code 的 SessionStart 钩子，另一个用于定义 VS Code 任务，在文件夹打开时运行。每个配置文件都能从另一款工具对应的目录启动 dropper，因此在不需要 npm install 或构建的情况下即可实现代码执行。
这种做法落入了许多依赖扫描器的视野之外。这类产品通常检查 manifest 和 lockfile 来识别已下载的软件包，却不会检查描述编辑器任务或 AI 编码工具行为的项目设置。这类风险与自动化 Action 被入侵的事件类似：可信的开发自动化流程，正在变成获取敏感访问权限的通道。
VS Code 工作区信任（Workspace Trust）和 Claude Code 的信任检查，可以阻止不受信任项目中的自动活动。但一旦开发者已经把熟悉的检出目录标记为可信，风险就会显著上升。
Kearns 建议团队在所有分支（而不只是主分支）中搜索异常仓库配置，并将解析得到的版本与受影响版本逐一比对。组织应该把仓库提供的配置视为可执行内容，并纳入审查、监控和应急响应检查。团队还应盘点编码工具，检查项目打开时读取了哪些文件，限制高价值令牌，并关注此前是否发生过 npm 软件包失陷事件，因为这可能意味着类似的凭据窃取行为正在酝酿。
ChainDrop 说明了一个现实：只保证依赖树安全，已经不足以保护开发者工作区。
03 失陷指标（IoCs）
注：IP 地址和域名已做去毒化处理（例如 [.]），以防止意外解析或超链接。请仅在可控的威胁情报平台（如 MISP、VirusTotal 或你的 SIEM）中恢复其原始格式。
参考来源：
ChainDrop npm Worm Poisons 444 Packages Through GitHub Actions and Trusted Publishing
https://cybersecuritynews.com/chaindrop-npm-worm/
发表于 1 小时前
|
查看: 3|
回复: 0
