本文将概述 Safe{Wallet}的签名过程以及替换 JavaScript 完成攻击的过程。

第二步: 发送交易给其他签名者

用户签名完交易后，交易会发送到 Safe{Wallet}的服务后端（transaction service）。服务后端会推送交易给其他用户来签名。

当用户在第一步中构造的是离线交易，因此也可以不发送到 Safe{Wallet}的服务后端，而是通过离线传递到方式来进行。不过这种方式不能利用  Safe{Wallet}提供的前端 UI 来完成后续操作，因此使用的难度较高。

第三步: 其他用户签名

其他用户在 Safe{Wallet}的 UI 收到有交易需要签名的通知后，通过点击交易详情完成签名过程。直到最后一个用户完成签名过程，交易上链。

攻击原因

在构造交易完交易后，交易会发送给钱包进行签名。而用户在 Safe{Wallet} 界面上看到的交易和实际真正最后签署的交易可能不是同一个交易。因为交给钱包来签名的交易是通过 Safe{Wallet}的 Javascript 来进行的。这个 JavaScript 脚本又是从  Safe{Wallet}的远程服务器下载下来的。

如果攻击者可以替换 Safe{Wallet}服务器上的文件（如 JavaScript），那么最终在钱包上签名的交易不是在 UI 上看到的合法交易，而是被替换掉的交易。

在 Bybit 被攻击的事件中，恰恰如此。根据 Bybit 公布的报告，攻击者在 February 19, 2025 的时候替换了 safe 服务器上的 JavaScript 文件。这个 JavaScript 文件替换了用户要签名的数据，最后构造了恶意升级的交易。

如上图所示，JavaScript 脚本修改了构造交易的过程，替换 CALL 交易到 DELEGATE_CALL，从而顺利完成 safe 合约的恶意升级，接管钱包。

教训

这一次攻击事件实际上给整个加密行业敲响了警钟。

首先，整个 crypto 行业面临的是不对称攻防的问题。中国有句俗语叫财不外露，而 crypto 行业由于强调透明化，资产存储在链上。而行业面临的对手是国家级力量的黑客组织。在这一不对称对抗下，任何一环节的薄弱都有可能是阿喀琉斯之踵。正如这个事件里面的 Safe 钱包服务器被攻击者攻破。

其次，在涉及到大额资金操作的情况下，能否在效率和安全上有更好的平衡也是行业需要考虑的问题。大额资金的操作是否需要有时间锁？是否需要分开存储？通过分散将单点故障的影响降低到最小。

最后，安全风控体系中最重要的一环是交叉验证。在涉及到大额资金转账的时候，要引入第三方来对交易进行风险确认，避免因为某一个环节出问题在全盘出问题。

BlockSec Phalcon 也会针对 Safe 推出安全监控方案，从第三方独立对交易进行安全确认，保护 Safe 以及其他多签钱包的交易安全。