本文将概述 Safe{Wallet}的签名过程以及替换 JavaScript 完成攻击的过程。
Safe{Wallet} 签名过程
根据前一篇文章内容, Safe{Wallet}是一个智能合约多签钱包,交易需要通过多个用户的签名才会最终上链执行。使用 Safe{Wallet}签名的一般过程如下。
第一步: 构造交易
交易的发起者通过 Safe{Wallet} UI 界面构造交易,包括普通的转账交易和合约交互交易。用户构造完交易需要进行签名。
Bybit 被盗事件背后的真相尘埃落定,根据 Bybit 公布的报告,事件是由于 Safe 的开发者机器被黑客组织攻破,替换了 Safe{Wallet}服务器上的代码,从而在用户构建交易的时候替换了等待签名的交易。
本文将概述 Safe{Wallet}的签名过程以及替换 JavaScript 完成攻击的过程。
根据前一篇文章内容, Safe{Wallet}是一个智能合约多签钱包,交易需要通过多个用户的签名才会最终上链执行。使用 Safe{Wallet}签名的一般过程如下。
第一步: 构造交易
交易的发起者通过 Safe{Wallet} UI 界面构造交易,包括普通的转账交易和合约交互交易。用户构造完交易需要进行签名。
第二步: 发送交易给其他签名者
用户签名完交易后,交易会发送到 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 以及其他多签钱包的交易安全。
【免责声明】市场有风险,投资需谨慎。本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资,责任自负。