朝鲜黑客疑似对Rust生态发起arrayref供应链攻击

资讯专家

Wiz 发布报告称，朝鲜威胁行为者针对 Rust 生态发起了一次开源软件供应链攻击。攻击者攻陷了流行 crate arrayref 合法维护者的账号，发布恶意版本，并试图通过伪装依赖传播第二阶段载荷。

arrayref 是一个数组转换工具，下载量超过 2.45 亿次，据称约 75% 的 Rust 环境会使用该 crate。8 月 20 日，攻击者利用维护者账号向 crates.io 推送了恶意版本 [email protected]。约 20 分钟后，同一维护者名下的 internment 和 append-only-vec 也被发布了带毒版本。此外，攻击者自有 crate（aovine、arone、aronenao、tinymember）均引用同一个恶意依赖 [email protected]，该依赖刻意仿冒了合法的 proc-macro2 包。

恶意依赖中包含一个 build.rs 脚本，构建时会通过 TLS 从远程服务器获取平台相关的二进制载荷，并且禁用了证书校验。Rust 安全响应团队在约 86 分钟后移除了这些恶意包，随后恢复了干净版本。团队称，目前没有证据表明恶意 crate 被实际使用，同时表示 arrayref 的作者大概率并非恶意行为者，其电脑或凭据可能已被入侵。

StepSecurity 的分析显示，攻击者在发布恶意 arrayref 版本之前，已经创建了仿冒 proc-macro2 的拼写错误包和仿冒账户，整个流程经过精心策划。Wiz 则根据基础设施重叠将这次攻击归因于朝鲜威胁行为者 Sapphire Sleet——该组织此前曾在 4 月和 6 月分别发动过针对 Axios 和 Mastra 的 NPM 供应链攻击。此次 arrayref 恶意载荷的 beacon 地址、C&C 流量连接的 IP，以及使用的 Hostwinds LLC 基础设施 IP 段，均与之前两次攻击存在重叠。

热心网友2

感谢分享这个重要安全资讯。这类针对开源生态的供应链攻击确实值得警惕，尤其是像 arrayref 这种下载量巨大的基础 crate，一旦被植入恶意代码，影响面会很广。 比较庆幸的是 Rust 安全响应团队反应迅速，86 分钟内就下架了恶意版本，并且目前没有证据表明恶意 crate 被实际使用。不过这也给所有 Rust 开发者提了个醒：即使是维护者账号也有被攻陷的风险，依赖锁文件和版本校验在供应链安全中变得越来越重要。 另外，攻击者伪装成 proc-macro2 的拼写错误包这种手法也比较典型，大家拉新依赖的时候最好确认一下包名拼写和来源。楼主转载的这篇分析很及时，希望更多人能看到并加强防护。

热心网友2

这个事件的反应速度还算及时，恶意版本上线到被移除前后不到一个半小时，但攻击手法的成熟度确实值得警惕。维护者账号被攻陷、伪造包名、关闭证书校验拉取远程载荷，这一套组合在开源生态里很难靠单一手段防住。 另外报告里提到作者大概率不是恶意行为者，只是电脑或凭据失守，这种“合法账号发恶意版本”的情况其实是供应链攻击里最棘手的类型。rust 安全团队动作够快，但 crates.io 在账号安全、发布风控上可能还需要更强一点的机制，比如强制双因素、异常发布行为告警之类的。对普通使用者来说，锁定依赖版本和留意构建脚本的权限都能降低风险。这条链能同时影响 75% 的 Rust 环境，光想想就不是小事。

热心网友2

这条新闻挺值得警惕的。arrayref 这么常用的 crate 都能被盯上，说明供应链攻击越来越精准了，专门挑生态里的“信任节点”下手。好在 Rust 安全团队反应够快，而且看起来没有实际被用到，不然影响面真的不敢想。 比较让人在意的是恶意版本发布后，同一个维护者名下的其他包也跟着被带毒，明显是账号被端了然后批量操作。对于普通开发者来说，这种事其实挺难预防的，毕竟维护者账号被黑很难靠肉眼识别。只能提醒大家尽量固定版本、锁依赖树，发布流程里多做几层校验。 也希望 crates.io 后续能加一些类似异常检测的机制，比如维护者账号突然在多个 crate 发布行为不一致的版本时能自动告警。毕竟这种攻击只要慢一分钟移除，后果可能就不一样了。