Bybit 史诗级漏洞的底层机制与代码级拆解
在过去一年所有Web3安全事件中最具代表性、技术含量最高、影响最大的案例无疑是 2025 年 Bybit 冷钱包攻击事件。这次攻击造成约 14–15亿美元损失并被认为是加密史上最大规模盗窃之一 。但真正值得研究的不是金额而是它揭示了一个新的攻击范式 攻击者不再“破解系统”而是“操控系统如何理解交易” 这标志着Web3安全从“代码漏洞时代”进入“语义操控时代”。这次攻击的起点并不在链上而是在前端。攻击者通过入侵 Safe 钱包前端(AWS S3)注入恶意 JavaScript使签名流程发生“表里不一”的变化用户看到的是正常交易实际签名的是恶意 payload核心篡改逻辑如下(真实攻击逻辑简化)// 保存原始交易origData structuredClone(safeTx.data);// 替换为恶意交易进行签名signedTx await sign(maliciousTx);// 再把数据改回“正常交易”signedTx.data origData; 本质签名与展示彻底脱钩这一步已经击穿了Web3最核心假设用户看到的 用户签名的 ❌接下来进入链上执行阶段真正的“核弹级漏洞”出现了delegatecall。Safe 多签的核心执行函数如下function execTransaction(address to, bytes memory data, uint8 operation) public {if (operation 1) {to.delegatecall(data);} else {to.call(data);}}关键点在于operation 1 → delegatecall而攻击交易中正是这一点被悄悄修改 。为什么这致命?因为 delegatecall 的执行语义是✔ 使用当前合约存储(资金还在原钱包)✔ 保留当前权限(还是多签权限)✔ 执行外部代码(攻击者控制) 等价于在你自己钱包里执行黑客代码 攻击者部署了一个“伪装成ERC20 transfer”的恶意合约function transfer(address _to, uint256 _value) public {// 并不转账而是修改存储masterCopy _to;}注意这个细节非常关键函数签名完全合法transfer(address,uint256) 钱包/UI几乎无法识别异常当 delegatecall 执行后发生了什么?Proxy.slot0 (masterCopy) attacker_contract也就是说 整个多签钱包的“逻辑大脑”被替换了根据链上分析这一步直接把 Safe 的实现地址改为攻击者控制的合约从而接管全部资产 。完整攻击链可以抽象为五步第一步前端注入(Supply Chain Attack)第二步伪造UI显示正常交易第三步签名恶意 delegatecall payload第四步修改 Proxy 的 implementation(slot0)第五步资产被完全控制并转移 整个过程没有破解私钥 没有传统意义上的“漏洞利用” 但系统完全沦陷这才是最可怕的地方。从安全模型看这次攻击击穿了三个核心假设1️⃣ 多签 安全 ❌2️⃣ 硬件钱包 安全 ❌3️⃣ 冷钱包 安全 ❌原因在于一个更深层问题安全依赖 人类正确理解交易但现实是 delegatecall ABI编码 人类不可读即使硬件钱包显示数据用户也很难识别异常 。这也是为什么攻击者可以成功拿到 3 个有效签名。从工程角度这个漏洞本质可以总结为一个公式系统安全 UI可信性 × 签名真实性 × 执行一致性而这次事件中UI ❌(被篡改)签名 ✔️(真实签名)执行 ❌(被替换) 系统整体失效更深层的教训是Web3 当前的“可升级代理模式”本身就是高风险设计典型 Proxy 结构contract Proxy {address public implementation;fallback() external {delegatecall(implementation);}} 一旦 implementation 被改写 整个系统逻辑被热替换 所有资产暴露从防御角度这类攻击已经无法通过传统审计解决必须升级安全范式第一前端完整性验证(SRI / Code Signing)