事件回顾

2025 年 2 月 21 日 UTC 时间下午 02:16:11，Bybit 的以太坊冷钱包 (0x1db92e2eebc8e0c075a02bea49a2935bcd2dfcf4) 遭到攻击，约 401,346 ETH、15,000 cmETH、8,000 mETH、90,375 stETH 和 90 USDT 被转移至未知地址，总价值约 14.6 亿美元。

攻击者通过钓鱼攻击诱骗 Bybit 的多重签名钱包签名者签署恶意交易。具体步骤如下：

攻击者提前部署了恶意合约，包含资金转移的后门功能。
篡改 Safe 前端界面，使签名者在 Safe 上看到的交易信息与实际发送至 Ledger 硬件钱包的数据不一致。
通过伪造的界面，攻击者成功获取三个有效签名，将 Safe 多签钱包的实现合约替换为恶意合约，从而控制冷钱包并转移资金。

Sygnia 受 Bybit 委托进行取证调查，确定攻击的根本原因，目标是识别攻击范围和来源，并减轻当前和未来的风险。最新报告见：Bybit Interim Investigation Report （https://docsend.com/view/rmdi832mpt8u93s7/d/rwecw3rumhqtgs6a）。

目前为止，取证调查突出显示以下发现：

对所有用于发起和签署交易的主机的取证调查发现，在 Safe 的 AWS S3 存储桶中的资源被注入了恶意 JavaScript 代码。
资源修改时间和公开可用的网络历史档案表明，恶意代码的注入是直接在 Safe 的 AWS S3 存储桶中进行的。
对注入的 JavaScript 代码的初步分析表明，其主要目的是操纵交易，在签名过程中有效地更改交易内容。
此外，对注入 JavaScript 代码的分析发现了一个激活条件，该条件仅在交易来源匹配两个合约地址之一时才会执行：Bybit 的合约地址和一个目前未识别的合约地址（可能与威胁者控制的测试合约相关）。
在恶意交易执行并发布后两分钟，新版本的 JavaScript 资源被上传到 Safe 的 AWS S3 存储桶。这些更新版本已删除了恶意代码。
初步发现表明攻击源自 Safe 的 AWS 基础设施。
到目前为止，取证调查未发现 Bybit 基础设施有任何被入侵的迹象。

对三个签名者主机的取证调查表明，攻击的根本原因是来自 Safe 基础设施的恶意代码。

在 Bybit 的基础设施中未发现被入侵的迹象。

调查仍在继续，以进一步确认这些发现。

从目前的信息来看前端并不是这次的主要问题所在，主要对这次攻击要负责的是 AWS 上面的存储服务被黑了，JavaScript 被篡改，导致在 Safe 前端发起的交易内容被修改。但是前端方面，如果 Safe 前端做了基本的 SRI 验证，即使这个 JavaScript 被改了，也不会出事，这样来看前端是要有一定责任的。当然 Bybit 肯定也是要负责的，首先他们自己用的硬件钱包没有显示具体交易信息他们就确认了，本身他们对 Safe 前端的信任就是不可靠的。

硬件钱包在处理复杂交易时存在局限性，无法完整解析和显示多重签名钱包的详细交易数据，导致签名者在未完全验证交易内容的情况下进行“盲签”。

黑客很擅长利用交互过程的设计缺陷骗取用户资产，如：利用 UI 劫持、欺骗用户签名；利用盲签名欺骗用户签名；利用 Permit 签名盗取用户的资产；利用 TransferFrom 零转欺骗用户进行钓鱼；采用尾号相同空头实施骗局；对 NFT 进行钓鱼等其它通用的钓鱼手法。

随着 Web3 技术的快速发展，前端安全与区块链安全的边界逐渐模糊。传统前端漏洞（如 XSS、CSRF）在 Web3 场景下被赋予了新的攻击维度，而智能合约漏洞、私钥管理缺陷等问题则进一步放大了风险。

接下来我们从两个场景来分析一下前端开发和安全问题的关联。

场景一：交易参数篡改 —— 界面显示转账，实际执行授权

示例：前端展示与链上执行分离

用户视角：

✅ 钱包弹窗显示 "Transfer 1 ETH to 0xUser..."

实际链上效果：

⚠️ 执行「 approve(attacker, unlimited) 」，资产可被随时转走

怎么办呢？EIP-712 结构化签名验证

1. 前端生成可验证数据

2. 智能合约验证签名

效果：任何前端参数篡改都会导致签名不匹配，交易自动回滚。

场景二：盲签劫持 —— 硬件钱包为何被攻破

示例：篡改 Ledger 解析规则

1.攻击者劫持前端代码，向硬件钱包发送伪造的 calldata：

2.Ledger 屏幕显示：

实际执行：「 approve(attacker, unlimited) 」

怎么办呢？硬件钱包语义解析 + 链上二次验证

1. 升级硬件钱包固件支持 EIP-712

2. 链上强制语义匹配

结语

前端安全与 Web3 安全的融合，既是挑战也是机遇。Bybit 被盗事件暴露了加密货币行业在安全管理和技术架构上的深刻问题。随着黑客攻击技术的不断演进，行业需从设备安全、交易验证和风控机制等多个层面全面提升防护能力，以应对日益复杂的威胁。前端开发要做的就是对访问 DApp 、连接钱包、消息签名、交易签名、交易后处理等环节不厌其烦的反复验证。实现从“被动修补”到“主动免疫”的跨越。唯有如此，方能在 Web3 的开放世界中守护每一笔交易的价值与信任。

当然链上合约的安全审计也是每个 Dapp 离不开的，ZAN AI Scan (https://zan.top/cn/home/ai-scan?chInfo=ch_WZ) 能够通过形式验证和人工智能辅助安全规范生成确保代码正确性，提供对数百万部署合约进行代码相似性和知识产权风险分析，提供全天候监控和即时通知，涉及可能影响您部署项目的零日漏洞和安全事件。并且拥有一个根据庞大的漏洞数据库进行优化的 GPT 模型，用于检测智能合约中各种现实世界的漏洞。

本文由 ZAN Team（X 账号 @zan_team）的 KenLee 撰写。

事件回顾

攻击者通过钓鱼攻击诱骗 Bybit 的多重签名钱包签名者签署恶意交易。具体步骤如下：

攻击者提前部署了恶意合约，包含资金转移的后门功能。

篡改 Safe 前端界面，使签名者在 Safe 上看到的交易信息与实际发送至 Ledger 硬件钱包的数据不一致。

通过伪造的界面，攻击者成功获取三个有效签名，将 Safe 多签钱包的实现合约替换为恶意合约，从而控制冷钱包并转移资金。

目前为止，取证调查突出显示以下发现：

对所有用于发起和签署交易的主机的取证调查发现，在 Safe 的 AWS S3 存储桶中的资源被注入了恶意 JavaScript 代码。

资源修改时间和公开可用的网络历史档案表明，恶意代码的注入是直接在 Safe 的 AWS S3 存储桶中进行的。

对注入的 JavaScript 代码的初步分析表明，其主要目的是操纵交易，在签名过程中有效地更改交易内容。

此外，对注入 JavaScript 代码的分析发现了一个激活条件，该条件仅在交易来源匹配两个合约地址之一时才会执行：Bybit 的合约地址和一个目前未识别的合约地址（可能与威胁者控制的测试合约相关）。

在恶意交易执行并发布后两分钟，新版本的 JavaScript 资源被上传到 Safe 的 AWS S3 存储桶。这些更新版本已删除了恶意代码。

初步发现表明攻击源自 Safe 的 AWS 基础设施。

到目前为止，取证调查未发现 Bybit 基础设施有任何被入侵的迹象。

对三个签名者主机的取证调查表明，攻击的根本原因是来自 Safe 基础设施的恶意代码。

在 Bybit 的基础设施中未发现被入侵的迹象。

调查仍在继续，以进一步确认这些发现。

接下来我们从两个场景来分析一下前端开发和安全问题的关联。

结语

本文由 ZAN Team（X 账号 @zan_team）的 KenLee 撰写。