警惕：针对知名 Rustacean 的定向攻击

Rust 安全团队于 9 月 17 日发出严厉警告：至少有一场定向攻击已从令人信服的视频通话发展为恶意 crate 发布。警惕：针对知名 Rustacean 的定向攻击并非泛泛的钓鱼提醒。攻击者正接触 Rust 项目成员和热门 crate 的所有者，因为一名维护者遭攻破，就可能让数千个下游开发环境暴露于风险之中。

这场攻击伪装成工作机会、咨询项目、投资讨论或合同邀约。在视频通话期间或之后，目标会遇到一个所谓的技术问题。攻击者提出的解决方案包括安装音频编解码器、运行一条命令，或打开一个由攻击者控制的项目。

这种社交工程手法此前似乎已经得逞。8 月 20 日，攻击者通过遭入侵的维护者账户发布了 arrayref、internment 和 append-only-vec 的恶意版本。这些代码会在编译期间执行，将一次普通的依赖更新变成通往开发者工作站和持续集成系统的入侵路径。

核心矛盾已不再只是可信代码与恶意代码之间的对立，而是个人信任与软件包发布权限之间的冲突。接到这些电话的人拥有发布权限，能够将一次私人账户失陷转变为软件供应链事件。

警惕：针对知名 Rustacean 的定向攻击已成为供应链警讯

Rust 项目正在向维护者发出警告，因为其认为攻击者的目标是获取发布权限，而不只是窃取单个文件或密码。

Adam Harvey 代表 crates.io 团队和 Rust 安全响应工作组发布了这份定向攻击警告。这些团队认为，一场持续中的攻击正以 rust-lang 成员及热门 crate 所有者为目标。

攻击者被怀疑意在攻破设备和账户，随后利用相关权限发布恶意软件。这一判断将私下的社交工程与公开的软件分发机制联系起来。开发者的工作站、浏览器会话、电子邮箱账户或 crates.io 凭据，都可能成为连接两者的桥梁。

报道所述的接触方式始于一个看似积极的机会。陌生人会提出工作、项目、顾问职位、投资交流或合同邀约。这类邀请经过了一定程度的针对性设计，足以值得回复；来电者还可能通过看似专业的个人资料来佐证其说法。

据报道，攻击者已构建看似可信的公司身份和 LinkedIn 页面。这些资产无需经得起严格的尽职调查；它们只需在收到未经请求的消息到安排通话之间的短暂时段内显得可信即可。

随后，通话中会出现人为制造的障碍。音频据称无法使用、似乎缺少编解码器，或需要运行一条命令才能恢复访问。另一种变体会将命令放入剪贴板，并引导目标将其粘贴到终端中。

这一时刻很关键，因为它将代码执行重新包装成故障排查。目标并非明知故犯地安装未知程序，而是在屏幕另一端有人等待的情况下，相信自己正在解决一个常见的通信问题。

Rust 的警告要求收件人对主动联络保持更高警惕，并使用自己已经信任的平台。它建议目标尽可能自行创建会议。这至少能从互动中移除一个由攻击者控制的环节。

维护者还被要求检查账户中是否存在意外活动，并确认已启用多因素认证。任何担心 crates.io 访问权限问题的人都可以联系其支持邮箱，而更广泛的事件则可上报给 Rust 安全团队。

这些建议有意保持简单。这场攻击危险的地方不在于某个晦涩的 Rust 漏洞，而在于一次可信的人际互动，随后发生了一个后果被隐藏的普通操作。

该警告并未断言所有报告的事件均由同一攻击者实施。Rust 团队明确表示，目前尚不清楚 6 月的尝试、arrayref 遭入侵事件以及当前活动是否属于同一场攻击。这种不确定性应限制归因，但不会降低眼前的风险。

这正是为什么警惕：针对知名 Rustacean 的定向攻击虽措辞克制，却具有超出字面含义的重要性。这份警告源于一次真实的发布权限失陷，而非假设性的威胁模型。

arrayref 事件展示了一名遭入侵维护者能够打开怎样的风险缺口

arrayref 攻击将一个合法维护者账户的控制权，转化为三个成熟软件包的恶意发布。

8 月 20 日 7:15 UTC，Rust 安全响应团队收到报告称 proc-macro1 含有恶意内容。调查人员确认，其构建脚本会下载远程载荷。

构建脚本是 Cargo——Rust 的包管理器和构建系统——在编译软件包时执行的代码。它可以完成合法的配置工作，但会在应用程序启动前运行。因此，它是隐藏恶意软件的理想位置。

团队发现，新发布的 arrayref 版本直接依赖 proc-macro1。近期的干净版本也被撤回，这可能会促使依赖解析转向恶意版本。攻击者在 internment 和 append-only-vec 上重复了这一模式；这两个 crate 均由同一维护者账户控制。

官方的arrayref 事件通告确认了三个被投毒的版本。arrayref 0.3.10 可用时长为 86 分钟，internment 0.8.7 为 90 分钟，append-only-vec 0.1.9 为 107 分钟。

从日历上看，这些时间窗口似乎很短。但它们足以让自动化依赖解析、开发者构建、编辑器工具和持续集成任务获取新软件包。

Rust 团队删除了恶意版本及六个相关 crate，恢复了被攻击者撤回的干净版本，并锁定了受影响的维护者账户。响应团队表示，其不认为该合法作者存在恶意行为。

相反，团队评估认为，该作者的计算机或凭据很可能已遭入侵。这一区别很重要，因为它说明了声誉的局限性。即使一位知名维护者没有主动添加攻击者控制的代码，一个熟悉的软件包仍可能携带这些代码。

安全研究人员估计，arrayref 的历史累计下载量约为 2.45 亿次。internment 约为 1440 万次，append-only-vec 则约为 450 万次。历史总下载量不等于受影响的安装量，但它们表明了账户选择为何如此重要。

攻击者不必植入一个无人知晓的软件包，再等待其被采用。他们将恶意依赖置于开发者本已接受的项目背后。被投毒的上层软件包在其他方面看起来依然熟悉。

这些 crate 还承担着不同的技术角色。arrayref 提供用于从切片中获取固定大小数组引用的宏。internment 支持驻留机制，即为重复值只存储一份共享副本。append-only-vec 提供一种并发向量，其已有条目不会被移除。

这些功能本身都不会让人自然联想到下载远程可执行文件。只有检查新增依赖及其构建行为后，这种不匹配才会显现。

因此，这一事件改变了此后所有虚假机会的背景。一份面向高影响力维护者的工作邀约，已不能仅被视为个人垃圾信息。它可能是另一场 Rust 供应链攻击的开局。

虚假面试骗局将职业礼貌转化为代码执行

攻击者利用维护者愿意评估机会的心理，随后将互动安排为：正常协作行为会执行其代码。

这场攻击最危险的部分发生在恶意软件抵达 crates.io 之前。它始于对目标的研究。软件包所有权、项目成员身份、会议露面记录和职业兴趣往往都是公开信息。

这些信息有助于攻击者打造相关的邀约。泛泛的招聘消息可能会被忽略；但提及维护者工作成果的提案更可能促成对话，尤其是在看似可信的公司网站和社交资料支持下。

Rust 开发者 Matt Mastracci 记录的一起 6 月事件，说明了其中所涉及的准备工作。一名伪造的投资代表就顾问工作与他接洽，安排了一场视频交流，随后发送了一项技术练习。

所提供的代码仓库看似包含一个普通的 TypeScript 项目。其说明要求接收者运行类型检查、测试和构建。Mastracci 的失败攻击分析发现，恶意代码隐藏在应用于 TypeScript 的补丁中。

运行预期的开发命令将触发该载荷。该仓库使用了多层隐藏手法，包括图像中的隐藏组件和一个分离进程。Mastracci 将其描述为一种远程访问木马，能够执行命令并访问文件。

由于他在运行前检查了项目，该事件并未导致其机器遭入侵。然而，它说明了为何简单的反钓鱼建议并不足够。攻击者并未发送粗糙的可执行附件；有害操作被嵌入在目标本应完成的工作中。

较新的视频通话模式将同样的压力压缩到了实时互动中。目标正在排查问题，而有人在等待。拖延会令人不适，因此接受建议的修复方式往往比结束会议更容易。

剪贴板变体对攻击者尤为有利。网站或通话参与者可以提供一条命令，却不必在有意义的上下文中展示其完整效果。将其粘贴进 shell，会把对话中的信任直接转移给操作系统。

所谓的编解码器也以类似方式运作。音频问题足够常见，因此这种解释听起来很寻常。然而，真正的会议平台不应要求从陌生联系人的自定义下载中获取基本音频功能。

最安全的理解并非每一场陌生会议都是敌对的，而是会议环境不应因安排会议的人而自动获得技术信任。

在已知平台上自行发起通话，可以改变这种平衡。将意外收到的代码仓库仅在不含生产凭据、可随时销毁的隔离环境中打开，也同样如此。这两项措施都不能证明来电者合法，但都能降低攻击者剧本的价值。

这类虚假面试骗局瞄准的也不只是 crates.io 密码。开发者机器中可能保存着 GitHub 会话、云凭据、SSH 密钥、签名材料、浏览器 Cookie、软件包令牌以及对私有源代码仓库的访问权限。

攻击者可以利用其中任何资产扩大入侵范围。最终出现的恶意 crate 或许只是可见结果，而被盗的组织凭据仍可能未被发现。

这构成了警惕：针对知名 Rustacean 的定向攻击背后的核心反转。攻击者主要利用的不是 Rust 的内存模型，而是围绕维护 Rust 共享基础设施人员的职业信任。

构建时执行将一次小型软件包变更转化为大范围暴露

这些恶意版本之所以危险，是因为 Cargo 会在构建期间执行攻击者的依赖项，早于下游开发者调用任何库函数。

被投毒的 crate 添加了一个名为 proc-macro1 的依赖项。这个名称与广泛使用的合法软件包 proc-macro2 极为相似。这属于拼写仿冒（typosquatting），即攻击者选择容易被误认为可信依赖项的名称。

恶意软件包复制了大部分合法项目的外观。其破坏性行为隐藏在构建脚本 build.rs 中。这种分离使父 crate 能保留预期的源代码，同时仅通过一行依赖声明引入载荷。

根据一项技术软件包分析，该脚本从编码片段中重建网络地址，并禁用了正常的证书验证。它会为 Linux、Windows、基于 Intel 的 macOS 或 Apple silicon macOS 选择相应载荷。

在类 Unix 系统上，该脚本会将可执行文件写入 /tmp/rust-setup 并直接启动，不等待其完成。在 Windows 上，它会创建一个 PowerShell 脚本，并借助 Visual Basic 脚本以隐藏进程的方式启动它。

构建本身仍可能显示成功。这一点至关重要，因为明显的失败通常会触发调查。能够正常编译的软件包，会让开发者更少理由去检查一个传递依赖项。

研究人员还观察到，被复制的软件包声明了额外的构建依赖项，包括网络和加密库。当一个小型宏软件包没有明确理由访问互联网时，这类新增项就很可疑。

另一项分析恢复了第二阶段恶意软件，并发现其具备更广泛的能力。据报告，其功能包括主机画像收集、浏览器数据检查、持久化、命令执行以及备用通信方式。

Wiz 的恶意软件调查发现，其基础设施与其他归因于朝鲜行为者的行动存在重叠。该分析关联了命令路径、托管网段及相关活动中的模式。

不过，基础设施重叠并不等同于确凿归因。服务器可能被重复使用、复制、租用，或被刻意选择来误导调查人员。Rust 项目也没有断言某一已识别组织应对所有相关活动负责。

谨慎的结论依然十分严重：这条技术攻击链被设计为能够躲过随意的源代码审查，并在常见开发操作期间执行。只需构建一个依赖该项目的工程即可。应用程序无需调用 arrayref、internment 或 append-only-vec。

这将潜在受害者范围扩展到了生产部署之外。刷新 lockfile 的开发者可能暴露于风险中，CI runner、自动依赖更新任务，或在分析项目时调用 Cargo 的编辑器工具同样如此。

lockfile 会记录构建时选定的确切依赖版本。经过提交和审查后，它可以揭示某个恶意版本是否进入过项目。然而，今天干净的 lockfile 并不能证明在暴露窗口期内，没有任何工作站解析过受影响版本。

这起 Rust 供应链攻击也表明，下载总量需要谨慎解读。数亿次历史下载并不意味着数亿次感染。恶意版本仅短暂存在，许多项目仍固定在更早的版本上。

即便如此，短暂发布的版本也可能触及敏感系统，因为软件包安装是自动化的。在恶意版本保持可用的每一分钟，热门程度都会为攻击者带来大量彼此独立的机会。

因此，代码路径与社会工程路径相互强化。瞄准维护者可获得发布权限；构建时执行则将这种权限转化为下游环境中的即时代码执行。

归因仍不确定，但防御结论并不因此改变

调查人员掌握了可信的协同攻击迹象，但现有证据无法证明每一起 Rust 事件都出自同一操作者。

9 月的警告串联起三项观察：Rust 开发者在 6 月遭遇了量身定制的接触；arrayref 维护者账户在 8 月被攻破；新的可疑联络持续到 9 月。

这些手法也具有可辨识的结构。攻击者构建专业身份，提出诱人的工作机会，建立实时互动，并引导目标执行代码。预期受害者拥有能够影响其他开发者的权限。

这种一致性支持协同行动的判断，但并不能证明存在单一指挥结构、资助方或恶意软件家族。

Rust 团队明确承认这一缺口。他们的警报称，并不清楚此前的定向攻击与 arrayref 攻击是否都属于同一场行动。负责任的报道必须保留这一限定。

与朝鲜的关联同样需要谨慎对待。安全研究人员已记录到，朝鲜相关行动会利用虚假招聘流程针对软件开发者。据报道，arrayref 恶意软件的一些基础设施和技术模式与此前已归因的行动存在重叠。

这些发现使这一假设值得重视，但并不能将其转化为确定事实。公开警告不应被解读为 Rust 项目的官方归因。

另一个未解问题涉及 arrayref 维护者最初是如何被攻破的。项目方认为该维护者的设备或凭据遭到入侵，但其公开事件通知并未提供完整的取证时间线。

这留下了多种可能性，包括被窃取的会话、凭据、浏览器数据或终端访问。9 月的文章称，该账户是通过类似攻击被攻破的，但未公开每一个技术步骤。

成功受害者的数量同样未知。公开记录确认了恶意软件包的发布，并记录了未成功的接触尝试；但未披露有多少维护者安装了软件、执行了命令，或私下报告了可疑通话。

下游感染数量也未公开。研究人员能够识别恶意软件包版本并估计软件包普及程度，但这不同于衡量其在有限暴露期内的实际执行情况。

这些信息缺口应影响事件响应。团队不应仅因项目依赖了曾受影响的 crate，就断言发生了感染；应确认特定机器上是否解析或构建过受影响版本。

相反的错误更为危险。团队不应因为恶意版本被迅速删除而淡化事件。本地缓存、CI 日志、lockfile 历史、终端遥测数据和凭据活动，可能保留当前 manifest 已无法显示的迹象。

构建过受影响版本的开发者，应将相关环境视为可能已被攻破。移除一个 crate 并不能撤销已经执行过的代码。该机器可访问的机密信息可能需要在另一台可信设备上进行吊销。

这场行动也挑战了“多因素认证足以解决账户安全问题”的假设。MFA 能降低许多凭据攻击的风险，但在已认证工作站上运行的恶意软件，仍可窃取会话或借助现有访问权限行动。

更强的软件包认证依然重要。硬件支持的凭据、最小化 token 范围、短期发布访问权限，以及将日常浏览与发布操作隔离，都可以降低暴露风险。但它们都无法让社会工程失去威胁。

真正的安全边界横跨人员、终端、身份系统和注册表。仅保护注册表登录，仍会留下太多通往发布权限的替代路径。

这正是 Be alert: targeted attacks on prominent Rustaceans 留下的持久教训。在归因尚未确定时，防御者依然可以根据已确认的机制和已经证明的影响采取行动。

维护者和工程团队接下来应关注什么

接下来最关键的信号，将是更多维护者报告、软件包发布控制措施的变化，以及将新的联络活动与已知恶意软件基础设施关联起来的证据。

首先，关注 Rust crate 所有者是否披露更多信息。若不同报告使用了相同的会议问题、公司身份、剪贴板命令或项目模板，将增强这是一次协同行动的判断。

若报告识别出不同的恶意软件或不相关目标，则会削弱单一行动的理论。但这仍将表明，多个组织都将开源维护者视为有价值的访问中介。

维护者应保留可疑电子邮件、会议链接、域名、个人资料、仓库地址和时间戳。这些细节可帮助响应人员比较基础设施，而无需个人自行作出归因判断。

其次，关注 crates.io 和其他注册表将如何调整发布控制措施。账户锁定和软件包删除限制了这次事件的影响，但这些措施是在恶意版本出现之后才发挥作用。

未来的控制措施可以聚焦于异常发布行为。一个软件包首次发布依赖项、撤回多个稳定版本，或新增意料之外的具备网络能力的构建组件，都构成可供审查的模式。

注册表必须在干预与开源维护者的独立性之间取得平衡。过度摩擦可能延迟合法的紧急发布，或将更多工作压在本已负担沉重的志愿者身上。

关键检验在于，新控制措施能否阻断高风险变更，同时不让日常维护变得难以承受。这是在发布自主权与生态系统遏制能力之间的权衡。

第三，关注社会工程接触与已恢复恶意软件之间是否出现更强的技术关联。匹配的域名、载荷证书、命令路径、源代码工件或托管基础设施，都将使归因更加明确。

若确认与已知操作者存在关联，可能改善跨生态系统的检测能力；若未能找到这种关联，则可能意味着这些技术正在多个组织间扩散。

工程组织无需等待这些问题得到答案。它们可以审查谁拥有软件包发布权限、发布凭据存放在哪里，以及这些凭据是否与日常浏览和视频通话共用一台工作站。

团队还应了解哪些构建在 8 月暴露窗口期内运行过。恶意版本为 arrayref 0.3.10、internment 0.8.7 和 append-only-vec 0.1.9。任何出现 proc-macro1 的情况都值得调查。

该审查应涵盖 CI runner 和本地开发缓存，而不只是当前仓库。若忽略历史记录，已清理的 lockfile 可能掩盖先前的执行。

组织还可以检查是否存在异常出站连接、新的持久化机制、异常浏览器访问和无法解释的凭据使用。确认执行后，应触发凭据轮换，并从已知干净的系统重新构建。

面对新的机会时，维护者应将社交验证与技术评估分开。通过独立渠道核实公司信息，在可信服务上创建会议，并拒绝自定义编解码器或复制来的终端命令。

意外收到的仓库应被视为不可信软件。其要求构建、测试或启动项目的指令，即使被包装成普通面试任务，本质上也是执行代码的请求。

最后的问题并不是 Rust 作为一种语言是否仍然安全。内存安全无法阻止可信构建脚本执行操作系统允许它执行的一切。

问题在于，生态系统能否保护那些权威地位已成为高价值目标的维护者。请警惕：针对知名 Rustacean 的定向攻击 应促使每个工程团队在下一名攻击者行动之前，识别出这些关键人员。审查发布权限，隔离发布凭据，并让可疑联络渠道能够被轻松上报。