Rust也救不了：Cargo供应链攻击深度解析

内存安全解决不了供应链问题

“换成 Rust 就能修好这个吗？”——这个问题几乎和编程本身一样古老。很多开发者相信，只要在构建流程里用上 Rust，那些被黑、被搞坏的隐患就会消失。Low Level 频道在这期视频里给出了一个清醒的答案：Rust 确实解决了内存安全问题，但它对供应链攻击无能为力。

就在今年 8 月 20 日，一个流行的 Rust Crate RayRef 出现了恶意版本 0.3.10。这个包本身非常轻量却强大——它允许你从数组中取出一个切片（slice），同时还能在编译时知道切片的长度，为 Rust 程序提供编译时安全检查。据视频作者介绍，录制时它已有约 2.54 亿次下载，可见影响面之广。

讽刺的是，一个专门用来做编译时安全检查的库，反而成了编译时执行后门的入口。这恰好印证了那个核心论点：语言层面的安全（内存安全）和生态层面的安全（依赖信任）是两个完全不同的战场。

攻击链拆解：从拼写抢注到编译时后门

恶意版本 RayRef 的手法并不复杂，却相当典型。它在依赖里注入了一个名为 ProcMacro1 的恶意依赖——这显然是对合法包 ProcMacro2 的拼写抢注（typosquatting）。而 ProcMacro2 本身只是 ProcMacro 的一个封装，Rust 生态混乱的命名让这种冒充更容易得手。

真正的杀招藏在 ProcMacro1 内部的 build.rs 脚本里。build.rs 是在执行 cargo build 时运行的构建脚本，其作用类似 NPM 生态里臭名昭著的 install 后置脚本（postinstall）。视频作者强调了一个关键点：光把恶意代码放进包里还不够，必须放进 build.rs，才能在构建时获得一个真正的执行时机。Cargo 会遍历依赖树到最底层，找到 build.rs 逐层向上执行。

后门的运行逻辑是标准的恶意软件套路：

• 从 Base64 片段拼接出一个 URL，把真实地址隐藏在编码中，绕过扫描器和防火墙检测；
• 疑似通过自定义例外规则禁用 TLS 证书校验，以绕过企业环境中用于流量拦截的恶意 CA；
• 根据操作系统（Mac / Windows 等）下载对应平台的 payload，写入 /Temp 目录并执行。

运行后的 payload 主要做信息收集：抓取主机名、用户名、操作系统详情、已安装应用列表，并读取 Chrome、Brave、Edge 的配置文件，查询浏览器的 SQLite 凭证存储。

**拼写抢注（Typosquatting）**是一种经典的供应链攻击手法，攻击者注册与热门包名极度相似的包名，利用开发者的手误或粗心来诱导安装。在 NPM 生态中，cross-env 对应的 crossenv、lodash 对应的 1odash 都是历史案例。这种攻击之所以奏效，是因为包管理器在解析依赖时不会主动提示"你是否想安装 XXX"，而是直接拉取与名称完全匹配的包。Cargo 在这方面没有额外的保护机制——crates.io 上的包名先到先得，任何人都可以抢注与知名包仅差一两个字符的名称。

build.rs 是 Cargo 构建系统的一个特殊约定：如果包根目录存在这个文件，Cargo 会在编译该包之前先编译并运行它，赋予其完整的系统访问权限（文件读写、网络请求、执行子进程等）。这个设计本是为了处理 C 语言绑定、代码生成等合法需求，但也构成了一个天然的任意代码执行入口。与 NPM 的 postinstall 脚本不同，build.rs 是在每次 cargo build 时都会重新执行的，而不仅仅是安装时触发一次，这意味着危害窗口更长、更难察觉。

被误读的“凭证窃取”

值得澄清的一个细节是：安全公司 Wiz 最初报道时称浏览器凭证被窃取，但视频作者指出这是个合理但不准确的猜测。实际上这些查询只读取了已保存的登录信息（元数据），并没有取回加密的凭证材料。

现代浏览器把凭证静态加密存储，运行时才从 HSM 或通行密钥处取出密钥解密。这次攻击并没有完成解密取材这一步，作者也坦言不确定攻击者为何没这么做。攻击最终通过注册表键值实现持久化，配置用一个字符串（“IMBotKing”）做对称加密——这个选择本身很奇怪，因为对称密钥基本等于公开。

幕后指纹：与朝鲜供应链攻击高度重合

这次攻击活动最引人关注的地方，在于它与近期归因于**朝鲜（DPRK）**的供应链攻击存在大量基础设施重合，包括早前针对 NPM 库 Axios 的攻击活动。

朝鲜攻击者的惯用手法通常是通过恶意面试或虚假求职身份渗透公司，最终目标往往是获得代码执行权限来挖加密货币——对一个被大规模制裁的国家而言，这是把资金导入本国经济的少数途径之一。

作者指出，这次威胁活动使用的某个 IP 地址，与此前 Axios NPM 攻击中用过的 IP 完全相同。当然他也如实呈现了另一种可能：这可能是两个不同攻击者共用同一 ISP 或 IP 段，也可能是 IP 资源有限的国家在两次行动中重复使用了同一地址。无论哪种解释，这条线索都把 Cargo 生态首次拉进了国家级供应链攻击的视野。

朝鲜黑客组织（通常被归因于 Lazarus Group 及其子组织）针对软件供应链的攻击已有多年记录。2023 年的 3CX 供应链攻击、2021 年对加密货币开发者的 npm 投毒，乃至更早的 SolarWinds 类似手法，均显示出这类国家级行为者将软件依赖链视为高价值渗透入口。其核心动机与普通网络犯罪不同：除了情报收集，加密货币挖矿与盗窃是规避国际制裁、获取外汇的重要手段，据估计朝鲜通过网络行动每年获取数亿美元资金。这也解释了为什么攻击目标的选择往往偏向开发者工作站——开发者通常拥有访问代码仓库、云账户和内部系统的高权限凭证，是"一次入侵、多点扩散"的理想跳板。

为什么 Cargo 上的攻击这么少见？

相比 NPM 生态里 Shai-Hulud 这类臭名昭著的蠕虫，针对 Cargo 的供应链攻击一直罕见。NPM 蠕虫的可怕之处在于自我传播：攻陷一个包后窃取其他 NPM 发布令牌，再用这些令牌发布更多恶意包，形成滚雪球式扩散。

作者坦诚更正了自己此前博客里的一个错误认知。他原本以为每个 Cargo 仓库有各自独立的凭证文件，攻击者必须知道目标维护哪些仓库才能精准窃取令牌。但实际情况是：每个用户的 Cargo Home 目录下都有一个统一的 credentials.toml 文件。

这意味着理论上蠕虫完全可以照搬 NPM 的玩法——直接扒取 Cargo Home 里的所有密钥，无需知道具体目标。换句话说，技术门槛并不存在。作者认为，Cargo 攻击稀少的真正原因很朴素：Rust 开发者的绝对数量远少于 JavaScript，攻击面小、性价比低。但他也判断，任何拥有包管理器、依赖令牌发布代码的语言，迟早都会遭遇这类攻击——Python、NPM 已经反复上演，而 Rust 正开始迎来越来越多的类似事件。

credentials.toml 文件位于用户的 Cargo Home 目录下（通常是 ~/.cargo/credentials.toml），以明文形式存储所有已登录 crates.io 账户的 API Token。这与 NPM 将 Token 写入 ~/.npmrc 的做法高度相似，也是 NPM 蠕虫得以横向传播的根本原因。一旦攻击者通过 build.rs 获得执行权限，读取这个文件只需一行代码，随后便可用窃取的 Token 向 crates.io 发布新的恶意版本，完成病毒式扩散。目前 crates.io 尚未强制要求发布时使用多因素认证（MFA），这与 NPM 在 2022 年大规模强制推行 MFA 之前的状态相似——后者正是在多次蠕虫事件后才采取了这一措施。

开发者该如何防范

如果你身处 Rust 生态，视频给出了几条实用建议：

• 排查依赖：检查你的 Cargo.toml 和已安装包中是否含有这些恶意包，发现立即移除；
• 轮换凭证：如果怀疑被入侵，先轮换凭证。目前虽无实际凭证被盗的直接证据，但不排除还有未被发现的 payload；
• 清理持久化：删除自动运行项里植入的 payload；
• 审计构建时依赖：这是最实用的一条。如果一个本不该联网的 crate 里出现了 reqwest（Rust 里用于发 HTTP 请求的库）这类依赖，尤其是在 build.rs 相关的构建时依赖中，那基本就是危险信号。

这次 RayRef 事件的启示很明确：安全不是选对语言就能一劳永逸的事。内存安全、类型安全解决的是代码本身的正确性，而供应链信任、依赖审计、令牌管理则是另一套必须独立建设的防线。在 AI 大量生成代码、依赖规模不断膨胀的当下，这道防线只会越来越重要。