惊魂一刻：一切看似正常的攻击

2025 年 2 月 21 日，BybitCEO Ben 发出一条推文：

在这条线程里，Ben 描述了他对于刚刚完成的一笔 safe 多签交互的困惑：所有签名者都操作了正确的地址，URL 也来自 safe，然而这笔看似 safe 协议要求更换冷钱包合约的签名却完成了一笔热钱包的资产转移操作。

随后各链上监控工具捕捉到的巨额（高达 15 亿的 ETH）转账 txn 被慢雾等安全公司确认为被盗。

面对问责，safe 直接否认了自己的前端被入侵这一可能，却未能提供更多信息。

事情扑朔迷离，大家更愿意相信可能是 bybit 被社工，而非 safe 这种 ETH 正统性光环加身的龙头项目的问题。

接下来是混乱的几天，市场陷入恐慌，用户人人自危，Bybit 一边救火处理提币踩踏一边拆借资金应对债务问题，Ben 则贡献了业内少有的教科书级别的危机公关处理。

事情的另一个主人公 Safe 协议在此期间默默下线了自己的服务自查，所有多签用户被暂停发送交易；

5 天后，Ben 带着详细报告杀回来了，报告直指 Safe 前端文件被替换导致 bybit 多签在操作时全程看到的都是错误的界面，简而言之，「bybit 对错误消息签了名却不知」

相比之下，Safe 的自查报告显得含糊其辞，关于被攻击的原因只有一句“through a compromised machine of a Safe{Wallet} developer ”.

完美犯罪？黑客的精密布局

关于 bybit 内部当时如何看到并处理这笔签名已经不可考，不过我们依然可以从黑客攻击交易中复盘完整的攻击过程和思路，黑客的攻击交易如下：https://etherscan.io/tx/0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882，打开链接发现交易原文不可读：

对这笔交易，我们用 DIY 的 txn 元数据解析工具（已开源，如有需求，文末自取）分析一下，把 etherscan 的链接复制进去发现黑客在构造一笔看起来像 ERC20 的转账交易：

但是此时值得注意的是：它的调用方式是 delegatecall, 这个词对非技术的同学可能比较陌生。delegatecall 就像是"借用别人的代码，但在自己家执行"。

想象你有一本菜谱（合约代码），通常你在厨房（合约 A）做菜时，用的是厨房里的食材。但 delegatecall 就像是：你借了邻居的菜谱（合约 B 的代码），但用的还是你自己厨房里的食材（合约 A 的状态 / 数据）。

所以如果黑客让你执行了一段恶意的"菜谱"，即使是在你的厨房操作，也可能把你的食材都搞坏了（修改了你的合约状态）。

因此 delegatecall 在合约调用中是相当危险（但某些场景很有用）的行为，这意味着你自己的领地门户大开，野蛮人可以直接进入，横冲直撞，烧杀抢掠。

而通常 transfer 方法执行的是 token 转账行为，修改的是用户的 token balance，这通常会保存在 token 合约中（因此绝不会用到 delegatecall 修改发送者的存储）。

这就意味着，对于一个有基本技术常识的人来说，delegatecall 几乎不可能和 transfer 同时出现。遗憾的是，当时 bybit 并没有用这样一个独立三方工具来校验他们签名的交易。

更有趣的是，既然黑客可以替换 safe.global 的前端代码，让 bybit 签任何交易（但是 bybit 看到的是他们想操作的交易），为什么他还要把这个攻击方法写成 ERC20 的 transfer 方法？

因为在这个过程中有人可能会用到冷钱包，而冷钱包对交易内容的显示不友好且受限，通常只能展示一串 0xabcdef 的 bytes，而在以太坊中，这串 bytes 的前四个字节用来表示你想要调用的方法（技术上叫做方法选择器），这个概念对普通用户很陌生，但是对一个执行过无数遍 token 转账的多签 / 冷钱包用户来说，0xa9059cbb 这几个 bytes 像刻在脑子里已经形成了肌肉记忆一样，一看就知道是 token transfer 了，降低防备心在所难免。

想象如果冷钱包的签名者看到的不是 0xa9059cbb（transfer）而是 0xabcdefgh，那会不会触发签名者的警觉机制从而想尽方法也要去验证交易原文内容？想到这里细思恐极，不得不感慨一句：细！太细了！

复盘黑客的攻击思路不难发现，他们不仅做了 safe.global 的前端篡改，连签名环节的各种可能性也都考虑到了，包括但不限于用户使用的钱包种类、可能的签名习惯等。

关于安全，多重算重？

在区块链安全领域，我们习惯性地信任品牌，因为这通常是最低成本的选择。然而，这种信任并非放之四海而皆准。尤其在多签钱包这一极其严肃的资产管理场景中，每笔交易都值得多个人、小心谨慎地确认和验证。既然我们已经接受让多人耗费数天时间来确保交易无误这样的高操作成本，那么使用独立的第三方工具进行一次 4 双重验证就显得必不可少。

值得注意的是，这并不是 Safe 第一次遭遇攻击。此前，他们也曾经历过 DNS 劫持的攻击事件，这再一次提醒我们，即便是被广泛信任的平台也无法百分之百地规避风险。因此，在进行涉及重大资产的多签交易时，我们不能仅依赖于品牌声誉，而是应建立起全面的独立验证机制。最终，真正的安全来自于多层次的防护措施，而不仅仅是对某一环节的盲目信任。

这几天我们已经看到了至少三笔大额资金攻击事件，区块链安全依然是一件任重道远的事情。关于安全，多重都不算重。

在协议 - 前端 - 人这个场景里，黑客当然会选择最弱的环节进行攻破。我们把协议上链实现“无需信任只需验证”，用社会关系与法律增加人的作恶成本，却得到了一个漏风的安全措施。这次是不诚实的前端注入，前端审查是根结问题。

所以，在真实的实践中，不要亡羊补牢，一定要防患未然。回到刚才的独立交易验证工具的思路，我们应该在第一个人发起并签名交易之后，为后续的签名者增加前端审查环节来验证交易原文，如果调用了小众交易也建议第一个签名者去工具里手动解析 calldata，以便后续签名者不再面对盲签的尴尬局面。

而这一步也很简单，只需要把 app.safe.global 中的交易分享链接直接粘贴在 safe-tx-verifier 中，就可以自动解析交易内容以及验证已经收集签名的有效性，同样可以在提交上链之前及时发现潜在漏洞。

Safe 用户的 2025 自保指南

1. 使用独立验证工具：如 safe-tx-verifier，或其他多签钱包交叉验证
2. 保持警惕心：即便是知名平台的操作也要二次确认
3. 重视多重验证：多检查一下，花不了几秒钟

2025，Stay Safe，但更要 Stay VERIFY！

这里送上我们自用的交易解析工具：safe-tx-verifier.mimir.global（这个工具不仅可以分析 safe 历史交易，还可以分析正在 pending 中的交易，对拦截恶意交易很有帮助）。

已开源！请放心使用。