Bybit事件二：Web2安全漏洞引发史上最大加密货币盗窃案

2025 年 2 月 21 日，Bybit 在一名攻击者通过社会工程学手段攻破 Safe{Wallet} 开发人员的电脑后，损失了约 15 亿美元。攻击者将恶意 JavaScript 代码植入 Safe{Wallet} 的 AWS S3 存储桶中，专门针对 Bybit 的交易进行攻击。注入的代码在签名过程中篡改了交易内容：Safe{Wallet} 前端界面显示的是一笔合法的交易，而发送到签名者 Ledger 设备上的实际有效载荷则将 Bybit 的 Safe 合约升级为了一个恶意实现，从而使攻击者获得了完全控制权。在签名并执行后，攻击者掏空了合约中的所有资产。关于此次事件的详细技术分解，请参阅我们之前的报告 [1]。

背景

Safe{Wallet}（原名 GnosisSafe）是一种使用 n-of-m 模型的多签钱包基础设施：执行交易至少需要 m 位签名者中的 n 位进行签名。

每个 Safe 钱包都以代理合约的形式部署。有两个存储变量对本次事件至关重要：

masterCopy（slot 0）：实现合约的地址。该合约包含了所有执行逻辑，包括签名验证和升级机制。代理通过 delegatecall 将所有调用委托给 masterCopy。
threshold（slot 4）：所需的最小签名数（n）。对于 Bybit 的 Safe 合约，该数值为 3。

由于代理使用 delegatecall，任何在 masterCopy 上调用的函数都会在代理的存储上下文中执行。这意味着 delegatecall 的目标可以直接覆盖 slot 0 处的 masterCopy，从而在单笔交易中替换整个实现逻辑。

漏洞分析

攻击路径横跨系统的三个层面，每一层都存在攻击者利用的结构性条件：

前端服务模型。 Safe{Wallet} 的前端 JavaScript 由 AWS S3 存储桶提供服务。在这种架构下，任何具有存储桶写入权限的人都可以修改为签名者构建交易的代码。虽然子资源完整性（SRI）哈希或代码签名等完整性验证机制可以降低此类风险，但它们目前尚未成为大多数 dApp 前端的标准做法。攻击者通过被攻破的开发人员机器获得了写入权限，并静默修改了所提供的 JavaScript 文件。

UI 显示与签名载荷之间的差异。 注入的 JavaScript 在 Safe{Wallet} UI 上显示看起来合法的交易，同时向 Ledger 硬件钱包发送了不同的载荷。Ledger 屏幕上显示的交易详情与 UI 上的会有所不同，但在硬件钱包屏幕上解读原始交易数据并不直观，对于复杂的多签操作更是如此。这种差异使得攻击者能够成功收集到恶意载荷所需的三个有效签名。

代理升级模型。 如背景中所述，delegatecall 在代理的存储上下文中执行目标代码。Safe 代理架构将所有调用通过 slot 0 处的单个 masterCopy 指针进行路由。重写此指针可将代理重定向到完全不同的实现（包括其签名验证逻辑），且这一切只需单笔交易即可完成。n-of-m 模型规定了谁可以发起交易，但一旦交易被批准并执行，它就有权更改实现本身。如果新的实现删除了签名验证逻辑，后续所有交易的多签保护实际上就失效了。

攻击分析

攻击分为三个步骤：恶意代码注入、实现替换和资产窃取。

第一步：恶意代码注入

攻击者攻破了 Safe{Wallet} 开发人员的机器，并将恶意 JavaScript 代码植入到提供前端服务的 AWS S3 存储桶中。注入的代码专门针对 Bybit 的 Safe 地址发起的交易。据 Bybit 首席执行官 Ben Zhou [2] 表示，Safe{Wallet} UI 显示的是合法交易，但发送到签名者 Ledger 设备上的载荷却是另一回事。签名者批准了 UI 上显示的交易，从而为恶意载荷提供了三个有效签名。

第二步：实现替换

攻击者提交了带有三个收集到的签名的恶意交易。Safe 代理将调用委托给 masterCopy，其 execTransaction() 函数验证了签名并执行了交易载荷：即对攻击者合约 (0x962214...5c7242) 的 delegatecall。由于该 delegatecall 在代理的存储上下文中运行，攻击者的 transfer() 函数将 slot 0 处的 masterCopy 值重写为了恶意实现地址 (0xbDd077...9516)。从这一刻起，所有对 Safe 合约的调用都被委托给了攻击者的代码。

第三步：资产窃取

随着 masterCopy 现在指向攻击者的实现，多签要求已不再适用。攻击者直接在 Safe 合约上调用了 SweepERC20() 和 SweepETH()。这些在攻击者实现合约中定义的函数在没有任何签名验证的情况下转移了所有持有的资产。总共执行了五笔转账交易，造成了约 15 亿美元的损失。

类型	描述	地址 / 哈希
合约	Bybit 的 Safe 合约	0x1Db92e2EeBC8E0c075a02BeA49a2935BcD2dFCF4
合约	原始 masterCopy 合约	0x34CfAC646f301356fAa8B21e94227e3583Fe3F5F
合约	恶意 masterCopy 合约	0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516
合约	攻击者合约 (即 transfer())	0x96221423681A6d52E184D440a8eFCEbB105C7242
交易	替换 masterCopy 合约的交易	0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882
交易	转移 15,000 cmETH 的交易	0x847b8403e8a4816a4de1e63db321705cdb6f998fb01ab58f653b863fda988647
交易	转移 90,375 stETH 的交易	0xa284a1bc4c7e0379c924c73fcea1067068635507254b03ebbbd3f4e222c1fae0
交易	转移 8,000 mETH 的交易	0xbcf316f5835362b7f1586215173cc8b294f5499c60c029a3de6318bf25ca7b20
交易	转移 401,346 ETH 的交易	0xb61413c495fdad6114a7aa863a00b2e3c28945979a10885b12b30316ea9f072c
交易	转移 90 USDT 的交易	0x25800d105db4f21908d646a7a3db849343737c5fba0bc5701f782bf0e75217c9

总结

此事件展示了链下基础设施的妥协如何演变成灾难性的链上损失。攻击者将 Web2 漏洞、前端篡改和代理升级串联成一条单一的攻击路径，在没有利用任何链上漏洞的情况下绕过了多签保护。

关键教训：

前端完整性应获得与链上安全同等的关注。 攻击链始于前端服务端。随着 dApp 越来越多地处理高价值交易，通过完整性验证（SRI、代码签名、可复现构建）并监控未经授权的更改来保护前端代码，已成为基本要求。
硬件钱包验证在实践中依然困难。 硬件钱包可以显示实际的签名载荷，但在小屏幕上解读复杂的多签交易数据是一个公认的可用性挑战。提高设备端交易摘要的可读性是钱包生态系统目前亟待解决的问题。
代理升级机制是高风险目标。 Safe 代理架构通过单个可升级指针路由所有逻辑。任何允许一步实现替换的机制都会集中风险。添加时间锁、二次确认步骤或为升级设置独立的监管方，可以减轻单笔交易受损所带来的冲击。