Drift Protocol 2.85亿美元黑客事件：为何交易可读性才是解决方案

Patrick Collins

为什么 Drift Protocol 黑客事件改变了 Web3 安全格局

这起价值 2.85 亿美元的 Drift 黑客事件通过线下社交工程攻破了一个 multisig。以下解释了为什么像 ERC-8213 这样的交易可读性标准才是解决之道。

为什么 Drift Protocol 黑客事件改变了 Web3 安全格局

这起价值 2.85 亿美元的 Drift Protocol 黑客事件并不是 Web3 历史上规模最大的一次黑客事件——Bybit 的 14 亿美元漏洞利用才是。但它可能是这个行业最需要理解的一次。原因如下。

本帖的视频版本

TL;DR

• Drift Protocol 是一个基于 Solana 的永续合约 DEX，于 2026 年 4 月 1 日遭到约 2.85 亿美元的攻击
• 这次黑客事件是通过社交工程攻破 multisig，而不是利用智能合约漏洞
• 攻击者与 Drift 贡献者在线下面谈，合作了六个月，并在动手前建立了真实信任
• 虽然使用了硬件钱包，但并没有起到作用——签名者无法验证自己正在签署的内容
• 系统性的解决方案是提升交易可读性：ERC-8213（Ethereum）和一个提议中的 SIMD（Solana）旨在让签名变得可验证

发生了什么

Drift Protocol 依赖一个 2-of-5 multisig 运行，使用的是 Squads，这是 Solana 上的标准 multisig 基础设施。团队已确认，所有 multisig 签名者都使用 cold wallet。

攻击者只需要获得两个批准。根据 Drift 的事后分析：

这次攻击是由预先签名的 durable nonce 交易，以及多个 multisig 签名者批准被攻破共同促成的，其实现方式很可能是有针对性的社交工程或交易误导。

这类漏洞利用本身——通过操纵签名者所批准的内容来攻破 multisig——并不新鲜。我们在 Bybit（14 亿美元）、WazirX（2 亿美元） 和 Radiant Capital（5000 万美元） 中都见过完全相同的模式。其手法一贯如此：

1. 入侵签名者的设备或环境
2. 展示看似合法、实则包含恶意数据的交易
3. 签名者在无法真正验证的情况下予以批准
4. 资金被转走

这笔漏洞利用交易大约在 12 分钟内完成。

为什么这次不同

此前所有由国家支持的加密黑客事件都依赖远程社交工程——虚假的工作机会、Telegram 消息，以及发给陌生人的恶意链接。线下面谈一直被认为对攻击者来说风险太高，因此团队可以把线下核验作为一种缓解手段。

而 Drift 的攻击者打破了这一假设。

根据 Drift 的披露：

Drift 贡献者在一场大型 crypto conference 上，被一群自称某量化公司的人接触，对方表示希望围绕该协议展开合作。他们技术娴熟，拥有可验证的职业背景，并且熟悉 Drift 的运作方式。

在接下来的六个月里，攻击者在 Drift 上接入了一个 Ecosystem Vault，存入了超过 100 万美元的自有资金，参与工作会议，并在多个国家的多场 conference 上与贡献者面对面会面。等到攻击实施时，这段关系已经持续了将近半年。

这让人联想到 XZ Utils 后门事件——一名贡献者通过多年建立信任，逐步渗透关键开源基础设施，最终植入后门。

有两点让这次升级对 Web3 的每个团队都意义重大：

1. 线下核验已不再是足够有效的筛选条件。 攻击者使用了中间人（并非朝鲜国民本人），但结果是一样的——Drift 团队相信自己在与一家合法公司合作。
2. 攻击时间线正在拉长。 在执行前先进行了六个月的关系建立。行业的检测模型并没有针对这种耐心程度进行校准。

单点修复措施（以及为什么它们还不够）

有一些具体步骤本可以降低攻击面。我们应该坦诚承认这一点：

交易验证。 虽然使用了硬件钱包，但签名者无法验证自己实际在签署什么。硬件钱包上的交易数据——尤其是复杂的 Solana instructions——会以原始 hex 形式呈现。要将成千上万的字符与预期值逐一比对，几乎不现实。这就是跨所有链都存在的盲签名问题。

代码执行卫生。 一名贡献者可能是在克隆了攻击者共享的代码仓库后被入侵的。Docker containers、dev containers 和沙盒环境就是为此而存在的。SEAL 的 Pascal Caversaccio 推荐使用 Qubes OS 实现完全隔离。

设备分离。 签名设备应在物理和逻辑上与工作设备分离。被攻陷的 laptop 不应以任何方式接触到 signing key。

这些措施都有效，在黑客事件发生前也都已经存在。但问题在于——如今没有一个是团队日常工作的默认路径。而这才是真正的系统性问题。

默认路径必须是安全路径

安全领域有一个概念叫 security fatigue——当做正确事情的认知负担高到一定程度，人们就会干脆不再去做。每一次黑客事件中，如果回应是“他们本该更小心”，那其实都是这个问题的症状。

以密码为例。几十年来，针对凭证复用的“解决方案”一直是告诉人们记住彼此不同的密码。这个建议在技术上是正确的，但在实践中并不可行。真正的修复来自于我们构建了基础设施——password managers、passkeys——让安全路径变成最容易走的路径。

这里也适用同样的模式。我们可以告诉每个 multisig 签名者，在硬件钱包上核对每笔交易的每一个字符。这个建议在技术上没有错，但在实践中没有人会这么做——因为那可能是 20 页的 hex 数据，而只要有一个字符出错，就可能造成灾难性损失。

这是把 fundamental attribution error 应用于安全：把情境性失败归咎于个人。解决办法不是更好的教育，而是更好的基础设施。

我们正在构建什么来修复这件事

ERC-8213：Transaction Digest Display（Ethereum）

ERC-8213 是我们为 Ethereum 生态提出的一项标准。它不再在硬件钱包上显示原始 calldata，而是显示一个单独的 32-byte digest。签名者在另一台设备上独立计算预期的 digest 并进行比对。只需验证一个 hash，而不是成千上万的字符。

这面向技术用户和企业签名者——也就是任何负责高价值 multisig 操作的人。

ERC-7730：Human-Readable Signing（Ethereum）

ERC-7730 是一个更长期的配套方案。它建立了一个 registry，由项目方提供结构化 metadata，将原始交易数据翻译成自然语言描述。这面向非技术用户和零售用户。

SIMD 讨论：将其带到 Solana

Drift 黑客事件发生在 Solana 上，而这些标准在那里尚不存在。我们已经在 SIMD repository 中开启了一个讨论，希望将这两种方法带到 Solana 生态——一个 transaction digest 的等效方案，以及一个 human-readable signing registry。

你现在应该做什么

如果你运营一个 multisig、管理 treasury，或者代表某个协议签署交易：

1. 去顶一下这些提案。 ERC-8213 和 Solana SIMD discussion 都需要社区支持。
2. 将签名设备与工作设备分开。 这是基本要求。
3. 对不受信任的代码使用容器。 Docker、dev containers、Qubes OS——任何能隔离执行的工具都可以。
4. 不要运行那些你尚未彻底核验过的人提供的软件。 即使是你在线下见过的人也一样。

这些是当下可以立刻采取的个人措施。但真正的修复——系统性的修复——是让钱包从一开始就不允许这类事情发生。

默认路径必须是安全路径。

• 原文链接： cyfrin.io/blog/drift-hac...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～