文章阐述 Safe{Wallet}的签名过程以及替换 JavaScript 完成攻击的过程。
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 以及其他多签钱包的交易安全。
关于BlockSec
BlockSec是全球领先的区块链安全公司,于2021年由多位安全行业的知名专家联合创立。公司致力于为Web3世界提升安全性和易用性,以推进Web3的大规模采用。为此,BlockSec提供智能合约和EVM链的安全审计服务,面向项目方的安全开发、测试及黑客拦截系统Phalcon,资金追踪调查平台MetaSleuth,以及web3 builder的效率插件MetaSuites等。
目前公司已服务超300家客户,包括MetaMask、Compound、Uniswap Foundation、Forta、PancakeSwap等知名项目方,并获得来自绿洲资本、经纬创投、分布式资本等多家投资机构共计逾千万美元的两轮融资。
Twitter:https://twitter.com/BlockSecTeam
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!