2025年2月21日，在一名攻击者通过社会工程学手段攻破了Safe{Wallet}开发者的机器后，Bybit损失了约15亿美元。攻击者将恶意JavaScript注入Safe{Wallet}的AWS S3存储桶，专门针对Bybit的交易。注入的代码在签名过程中改变了交易内容：Safe{Wallet}用户界面显示的是一笔合法交易，而实际发送给签名者Ledger设备的数据包则将Bybit的Safe合约升级到了一个恶意实现，从而使攻击者获得了完全的控制权。一旦签名并执行，攻击者就耗尽了合约中的所有资产。我们早先的报告[1]中提供了详细的技术分析。
背景
Safe{Wallet}（又名GnosisSafe）是一种使用“n选m”模式的多重签名钱包基础设施：执行一笔交易至少需要从总共m个签名者中获得n个签名。
每个Safe钱包都部署为一个代理合约。在此事件中，有两个存储变量至关重要：
masterCopy（槽位0）：实现合约的地址。该合约包含所有执行逻辑，包括签名验证和升级机制。代理通过delegatecall将所有调用委托给masterCopy。threshold（槽位4）：所需的最少签名数量（n）。对于Bybit的Safe，此值为3。
由于代理使用delegatecall，在masterCopy上调用的任何函数都在代理的存储上下文中执行。这意味着delegatecall的目标可以直接覆盖槽位0中的masterCopy，在一笔交易中替换整个实现。
漏洞分析
攻击路径横跨系统的三个层级，每一层都提供了攻击者利用的结构性条件：
前端服务模型。 Safe{Wallet}的前端JavaScript是从AWS S3存储桶提供的。在这种架构中，任何拥有该存储桶写入权限的人都可以修改用于构建交易并发送给签名者的代码。完整性验证机制，如子资源完整性（SRI）哈希或代码签名，可以缓解此风险，但它们尚未成为大多数dApp前端的标准做法。攻击者通过被攻破的开发机器获得了写入权限，并悄无声息地修改了提供的JavaScript。
UI显示与签名数据包之间的差距。 注入的JavaScript在Safe{Wallet}用户界面上显示了一笔看起来合法的交易，同时向Ledger硬件钱包发送了不同的数据包。Ledger屏幕上显示的交易详情会与用户界面不同，但要在硬件钱包屏幕上解读原始交易数据并非易事，尤其对于复杂的多重签名操作。这种差距使得攻击者得以收集到三个用于恶意数据包的有效签名。
代理升级模型。 如背景中所述，delegatecall在代理的存储上下文中执行目标代码。Safe代理架构通过槽位0中的单个masterCopy指针路由所有调用。覆盖此指针可以将代理重定向到完全不同的实现，包括其签名验证逻辑，只需一笔交易。n选m模型控制着谁可以发起交易，但一旦交易被批准并执行，它就可以修改实现本身。如果新的实现移除了签名验证，那么对于所有后续交易，多重签名保护将不复存在。
攻击分析
攻击分三个步骤进行：恶意代码注入、实现替换和资产盗窃。
步骤1：恶意代码注入
攻击者攻破了一台Safe{Wallet}开发者的机器，并将恶意JavaScript注入了提供前端的AWS S3存储桶。注入的代码专门针对来自Bybit Safe地址的交易。据Bybit首席执行官Ben Zhou [2]称，Safe{Wallet}用户界面显示的是一笔合法交易，而发送给签名者Ledger设备的数据包则不同。签名者按照用户界面的显示批准了交易，从而使攻击者获得了该恶意数据包的三个有效签名。
步骤2：实现替换
攻击者提交了带有这三个已收集签名的恶意交易。Safe代理将调用委托给masterCopy，其execTransaction()验证了签名，然后执行了交易数据包：一个delegatecall到攻击者的合约（0x962214...5c7242）。由于这个delegatecall在代理的存储上下文中运行，攻击者的transfer()函数用恶意实现地址（0xbDd077...9516）覆盖了槽位0中的masterCopy值。从这一点开始，所有对Safe合约的调用都将委托给攻击者的代码。
步骤3：资产盗窃
现在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代理架构通过单个可升级指针路由所有逻辑。允许一次性替换实现的任何机制都集中了风险。增加一个时间锁、二级确认步骤或独立的监管者进行升级，可以降低单笔被攻破交易的影响。
参考
关于BlockSec
BlockSec是一家全栈区块链安全和加密合规提供商。我们构建产品和服务，帮助客户在协议和平台的整个生命周期内进行代码审计（包括智能合约、区块链和钱包）、实时拦截攻击、分析事件、追踪非法资金，并满足AML/CFT义务。
BlockSec在知名会议上发表了多篇区块链安全论文，报告了多个DeFi应用的零日攻击，阻止了多次黑客攻击挽救了超过2000万美元，并确保了数十亿美元的加密货币安全。
-
官方Twitter账号：https://twitter.com/BlockSecTeam
