2025 年 2 月 21 日，加密货币交易所 Bybit 遭遇了 Web3 领域有史以来损失最大的攻击，其 Safe 多签钱包中近 15 亿美元资金被朝鲜黑客洗劫一空。
DARKNAVY 团队长期关注 Web3 领域安全动态，并在Bybit安全事件后，从攻击者、开发者、签名者视角全方面还原了 Bybit 被攻击的过程。
攻防解读
Safe 钱包得益于多签机制的安全性，被广泛作为多签冷钱包用于资产托管。Bybit 自 Gnosis Safe（ Safe{Wallet} 前身）时期即采用该方案管理巨额 ETH 资产，此次事件中被盗的15亿美元资金正源于此 Safe 钱包。
Safe{Wallet} 是以太坊生态上热门的资产管理工具，其最核心的部分 Safe{Core} 实现了支持多重签名验证的智能合约账户，即 Safe 钱包。它允许用户设置多个签名者（owner），以及执行交易所需的验证的签名数量。分散管理每个签名者的私钥，可以有效降低单点故障风险、实现更灵活的治理。
Safe{Wallet} 不仅仅是智能合约。它还包含一个配套的 off-chAIn 网页平台，为用户提供直观的界面，从而让用户可以方便地创建和管理 Safe 钱包，发起和批准多签交易，与各种 dApp 交互等；在前端网页的背后，有庞大的一套后端为管理交易队列、聚合签名、交易记录等接口提供支持。
01
社工攻击 → 供应链攻击
整个事件中的最先遭受攻击的并不是 Bybit，而是 Safe{Wallet} 团队的开发人员。
黑客首先找到 Safe 团队的开发人员，通过社会工程学的方式诱骗其执行包含木马的恶意程序。黑客控制了开发人员的电脑后，搜集得到了 AWS 会话 token 等各类凭据，以及存放 Safe 网站前端资源文件的 S3 对象存储的控制权。
黑客伪装技术小白向开发人员求助（示意）
黑客真正的目标是窃取 Bybit 在 Safe{Wallet} 中的资金。于是，他们向 Safe 网站悄悄植入了针对性的恶意 JavaScript 代码。
02
被篡改的例行交易
Bybit 的 Safe 钱包共设置了 6 位签名者，每次交易需要其中 3 位进行批准。Bybit 还为钱包配置了提案人（proposer）的角色，经提案人签名，可以向钱包提交新的交易请求，但提案人的签名不计入交易需要的签名总数。
提案人首先发起向温钱包例行转账的请求，并通知签名者处理。
签名者在网页内核实交易参数无误后点击签名按钮，恶意 JavaScript 却向硬件钱包提交了篡改后的数据，但签名者没有注意核对，就确认了恶意请求。而Bybit的三位签名者竟然都犯了同样的错误。
篡改前后的交易参数对比（示意）
当三人均完成签名后，钱包的所有资产在短时间内便被清空，刷新网页后连钱包的基本信息都无法再加载。
03
链上攻击分析
提案人原始的转账提案是调用代币合约的 transfer(address,uint) 方法；篡改后的交易变成了向恶意合约发起调用，方法虽是看似无害的 transfer(address,uint)，但最重要的参数 Operation 字段由 0 变成 1，即调用方式了由普通调用（call）变成了 delegate call。
Delegate call 是以太坊智能合约中的一种特殊调用方式，它允许当前合约执行另一个合约的代码，但使用的上下文仍然是调用者合约。任何对状态的改动也都是对调用者合约进行的。
代理合约正是利用delegate call的这一特性，实现了智能合约的可升级性。代理合约负责存储数据，而将逻辑处理委托给另一个逻辑合约。只需更新逻辑合约的地址，就能在不改变数据存储的情况下，实现合约升级。
然而，如果delegate call的目标是恶意合约，由于它是在调用者合约的上下文中执行，可能导致资金被窃取、数据被修改等严重后果。
Safe 钱包实例在本质上是代理合约，所有代码逻辑部署在 Safe MasterCopy 中，MasterCopy 的地址就保存在钱包实例的 storage[0] 位置。攻击者利用恶意合约“升级”了 Safe 钱包，替换了钱包的逻辑实现地址，从而能够利用新的逻辑进行任意提款操作。
恶意合约：在转账接口下，实现的逻辑却是修改storage[0]
破绽百出的骗术
在整个事件中，"欺骗"是朝鲜黑客最主要的武器。如果他们针对 Safe 团队的欺骗策略失败，他们也许还有很多其他技术手段进行攻击；但篡改前端代码守株待 Bybit 的骗术，实际上存在诸多漏洞。根据 verichains 对签名者电脑的取证分析报告，黑客篡改了两个前端 JavaScript 文件。
在重现这一篡改过程时，我们发现该骗局并不完美，前端页面存在多个可能暴露攻击痕迹的地方：
在签名完成时跳出的成功提示中，safe client gateway 会根据交易生成 "human description"，信息中会包含转账的数额、代币名称、收款地址信息，而这三要素在事件中没有一个是匹配的：攻击者把要替换的实现地址放在参数中，并将转账数额设置为 0，而恶意代币合约本身没有代币名称的收录。
正常代币转账及恶意合约“转账”消息示意对比
点击成功提示中的 "View transaction"，能看到实际签署的真实数据，以及对 delegate call 的显著提示。
对异常 delegate call 的提示（示意）
在第一位签名者完成签名后，第二位签名者的主页会发生一些变化：队列中的交易数由 1 个变成了 2 个；Pending transaction 从原本的例行转账变成了"Contract interaction"。从这个界面出发，如果他点击了交易队列或"Contract interaction"都可能会发现问题，但右上角通知指向的还是原始交易的确认页面。
发生恶意签名前后页面对比（示意）
发送恶意签名后，交易队列会显示 "Contract interaction" 与例行转账的 nonce 冲突，并且前者已有 1 个签名，后者还停留在无确认的提案状态。
Nonce冲突的两个交易（示意）
由于所有签名实际都是针对恶意请求的，每个签名者在检查原始的例行交易时，会看到它已确认的签名数始终是 0。
攻击完成后，Safe 页面显示余额清零、钱包损坏。
Bybit钱包目前已无法加载
要让攻击更难露馅，更缜密的攻击者一方面会进一步修改前端界面，对各种 API 接口或前端组件绘制接口进行 Hook，确保各种界面和提示信息都与正常情况一致；另一方面最小化恶意交易和原始交易的参数差异、保持原始 data 字段完全不变、部署与真实代币具有相同地址前后缀的恶意代币合约。
当然事实证明，即使是这样破绽百出的骗局，在毫无防备的受害者面前就是奏效了。
缺位的防御机制与安全意识
Safe 虽然所有代码全部开源，但其 off-chain 部分的部署仍然没那么公开透明。多签机制本能排除单点故障，Safe 前端却成为本次事件的单点故障源。
尽管 Bybit 的签名人员在事件期间的不细心直接导致了损失，但其实也有不少可以预防的措施没有落实。
01
过度依赖第三方
Bybit CEO Ben 在采访中提到，许多交易所都使用内部解决方案保存资金，Bybit 也采用同样的做法保存以太坊之外的资产。对于以太坊，他们过去没有向智能合约方向投入足够的资源，这也是 Ben 最大的遗憾之一。
不能过度依赖第三方不意味着需要完全独立。事实上 Safe{Wallet} 公开透明的合约部分经过了长期的验证，做得也足够优秀，本次出问题的也是 off-chain 部分。就算 Bybit 不了解智能合约，也不打算重新写一套 off-chain 平台，哪怕仅是将 Safe 的开源平台本地化部署一份，都能在受益于第三方能力的同时将自身的安全命运掌控在自己手中。
Safe{Wallet} 平台实际上也集成了许多第三方工具。在交易签名的界面上，有单独一栏 Transaction checks 提供了 tenderly 的交易模拟功能，使用它可以方便地看到对所有资金流动记录、事件日志、状态改变的预测。如果用它对恶意交易进行一次模拟，隐匿的攻击就无处遁形了。
tenderly 的交易模拟功能
02
缺少合约知识储备
Bybit 和其他一些机构不仅缺乏独立实现安全合约的能力，对 Safe 本身的合约执行逻辑也缺乏了解。攻击发生后，Bybit 联系 Safe{Wallet} 团队临时关闭了部分服务，这直接导致了后续其他机构向 Bybit 放款以及 Bybit 从另一 Safe 钱包提取 USDT 时遇到了“困难”。
然而，实际被暂停的仅是 off-chain 平台服务，略懂智能合约的人查阅 Safe 的源代码，便能明白如何在不依赖平台的情况下，自行签名并提交执行交易。
03
固步自封
正如前文所述，Bybit 是 Safe 的早期用户，其遭受攻击的合约仍停留在四年前部署的 1.1.1 版本。尽管该版本本身不存在漏洞，但却无法享用新版本引入的 Guard 等安全特性。新版本 Safe 实现了模块化的 Guard 机制，通过在交易执行前后增加调用 Guard 检查函数的钩子，Guard 能够检测到非预期行为，并将整个交易回滚。
Safe的亡羊补牢
在调查报告中，Safe 记录了他们的举措，包括完整的基础设施重置、增强的恶意交易检测、全面的监控系统、交易队列重置、UI 改进等等。
Safe针对前端增加了许多关于二次确认的提示，在交易模拟检查一节也加入了指向 OpenZeppelin 的 Safe Utils 的链接。
Safe前端新增警示
处理多签交易的后端也对 delegate call 进行了严格的限制，只允许钱包向 MultiSend、SignMessageLib、SafeMigration 等白名单合约发起 delegate call。
safe-transaction-service 新增限制delegate call的commit
然而，一旦足够精明的黑客再次发起攻击，所有的 off-chain 机制都可能被绕过、甚至其他链上防御也能通过欺骗用户进行解除。因此，最核心的安全防线仍然是牢牢守护密钥 —— Not Your Keys, Not Your Coins。
参 考：
[1] https://x.com/safe/status/1897663514975649938
[2] https://coinacademy.fr/wp-content/uploads/2025/02/Bybit-Incident-Investigation-Report.pdf
[3] https://followin.io/en/feed/16568414
[4] https://mp.weixin.qq.com/s/rB4XeIBATAb1zHZ9WVyxAg
