Bybit 事件：一次 Web2 入侵如何造就史上最大加密货币黑客案

#2 Bybit 事件：一次 Web2 入侵如何造就史上最大加密货币黑客案

原文标题： #2 Bybit Incident: A Web2 Breach Enables the Largest Crypto Hack in History
原文链接： https://blocksec.com/blog/bybit-incident-a-web2-breach-enables-the-largest-crypto-hack-in-history
作者 / 机构： BlockSec
原文发布日期： 2026-02-09
分类： Code Auditing（代码审计）
译文说明： 全文简体中文翻译（非摘要）。IOC、哈希、合约地址、交易哈希、函数名、URL、代码等保持英文原文。
翻译日期： 2026-09-16（Asia/Shanghai）

免责声明： 本译文为非官方简体中文翻译，仅供安全研究与防御学习参考。版权归 BlockSec 及原作者所有。如有歧义，以英文原文为准。

图：Bybit 事件分析封面

2025 年 2 月 21 日，攻击者通过社会工程（social engineering）攻陷一名 Safe{Wallet} 开发者的机器后，Bybit 损失约 15 亿美元。攻击者将恶意 JavaScript 注入 Safe{Wallet} 的 AWS S3 存储桶，并专门针对 Bybit 的交易。注入代码在签名过程中篡改交易内容：Safe{Wallet} 界面显示的是一笔合法交易，而实际发送到签名者 Ledger 设备的载荷，会将 Bybit 的 Safe 合约升级为恶意实现，从而让攻击者获得完全控制权。一旦签名并执行，攻击者抽干了合约中的全部资产。更详细的技术拆解见我们此前的报告 [1]。

背景

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

每个 Safe 钱包部署为代理合约（proxy contract）。与本次事件密切相关的两个存储变量是：

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

图：Safe 代理中的 masterCopy（slot 0）与 threshold（slot 4）

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

漏洞分析

攻击路径贯穿系统的三层，每一层都存在攻击者可利用的结构性条件：

前端服务模型。 Safe{Wallet} 前端 JavaScript 由 AWS S3 存储桶提供。在此架构下，任何对存储桶具备写权限的人都可以修改为签名者构造交易的代码。子资源完整性（SRI）哈希或代码签名等完整性校验机制可以缓解该风险，但它们对大多数 dApp 前端尚未成为标准实践。攻击者通过被攻陷的开发者机器获得写权限，并静默修改了所服务的 JavaScript。

界面展示与签名载荷之间的鸿沟。 注入的 JavaScript 在 Safe{Wallet} UI 上展示看似合法的交易，同时向 Ledger 硬件钱包发送不同的载荷。Ledger 屏幕上显示的交易细节本应与 UI 不同，但在硬件钱包小屏上解读原始交易数据并不容易，尤其是对复杂的多签操作。这一鸿沟使攻击者得以收集到针对恶意载荷的三个有效签名。

代理升级模型。 如背景所述，delegatecall 在代理的存储上下文中执行目标代码。Safe 代理架构将所有调用经由 slot 0 处的单一 masterCopy 指针路由。覆写该指针会将代理重定向到完全不同的实现——包括其签名验证逻辑——且只需一笔交易。n-of-m 模型约束的是谁可以发起交易，但一旦交易被批准并执行，它可以改写实现本身。若新实现移除签名验证，则后续所有交易的多签保护实质上失效。

攻击分析

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

步骤 1：恶意代码注入

攻击者攻陷 Safe{Wallet} 开发者机器，并将恶意 JavaScript 注入服务于前端的 AWS S3 存储桶。注入代码专门针对来自 Bybit Safe 地址的交易。据 Bybit CEO Ben Zhou [2] 所述，Safe{Wallet} UI 显示的是合法交易，而发送到签名者 Ledger 设备的却是不同载荷。签名者按 UI 所示批准了交易，从而让攻击者获得针对恶意载荷的三个有效签名。

图：步骤 1 — 恶意 JavaScript 注入与 UI/签名载荷不一致

步骤 2：实现替换

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

图：步骤 2 — 通过 delegatecall 覆写 masterCopy

图：步骤 2 — 实现替换后的委托路径

步骤 3：资产窃取

在 masterCopy 已指向攻击者实现后，多签要求不再适用。攻击者直接在 Safe 合约上调用 SweepERC20() 与 SweepETH()。这些函数定义在攻击者实现合约中，在无任何签名验证的情况下转移全部持有资产。共执行五笔抽干交易，合计损失约 15 亿美元。

图：步骤 3 — 调用 Sweep 函数抽干资产

图：步骤 3 — 多笔抽干交易概览

相关合约与交易

总结

本事件表明，链下基础设施的沦陷如何级联成灾难性的链上损失。攻击者将一次 Web2 入侵、前端篡改与代理升级串成单一攻击路径，在未利用任何链上漏洞的情况下绕过多签保护。

关键教训：

• 前端完整性应与链上安全同等重视。 攻击链始于前端服务层。随着 dApp 越来越多地中介高价值交易，用完整性校验（SRI、代码签名、可复现构建）保护前端代码，并监控未授权变更，已成为基线要求。
• 硬件钱包核验在实践中仍然困难。 硬件钱包可以显示实际签名载荷，但在小屏上解读复杂多签交易数据是已知的可用性挑战。提升设备端交易摘要的可读性，仍是钱包生态的开放问题。
• 代理升级机制是高杠杆目标。 Safe 代理架构将全部逻辑经由单一可升级指针路由。任何允许一步完成实现替换的机制都会集中风险。为升级增加时间锁（timelock）、二次确认步骤或独立监护人（guardian），可以降低单笔被攻陷交易的影响。

参考文献

1. BlockSec: Bybit $1.5B Hack In-Depth Analysis
2. Bybit CEO Ben Zhou X Broadcast

关于 BlockSec

BlockSec 是全栈区块链安全与加密合规服务提供商。我们构建产品与服务，帮助客户进行代码审计（包括智能合约、区块链与钱包）、实时拦截攻击、分析事件、追踪非法资金，并履行 AML/CFT 义务，覆盖协议与平台全生命周期。

BlockSec 已在权威会议发表多篇区块链安全论文，报告过多个 DeFi 应用的零日攻击，拦截多起黑客攻击并挽回超过 2000 万美元，并保障了数十亿美元规模的加密资产。

• 官网：https://blocksec.com/
• 官方 Twitter：https://twitter.com/BlockSecTeam