SharkTeam对此事件进行了技术分析,并总结了安全防范手段,希望后续项目可以引以为戒,共筑区块链行业的安全防线。
二、事件分析
该事件涉及两个不同链的交易hash以及攻击者地址,分别如下:
(相关资料图)
(1)PoS链交易hash:0xbddb0cc8bc9949321e1748f03503ed1a20dd618fbf0a51dc5734c975b1f8bdf5
(2)PoW链交易hash:0x9c072551861ce384203516f4d705176a2d2e262d5b571d853467425f1a861fb4
(3)攻击者地址:0x82FaEd2dA812D2E5CCed3C12b3baeB1a522DC677
首先,我们对比发现两笔交易访问的合约相同,并且inputdata完全相同,即调用了同一个合约的同一个函数并且参数相同,根据相同的方法签名ID0x23caab49可知,黑客调用safeExecuteSignaturesWithAutoGasLimit函数。
因此,攻击者通过OmniBridge 转移200WETH,然后在PoW链上重放了相同的Inputdata,获得了额外的200 ETHW。
此时,我们对这里的重放操作抱有怀疑态度。因为,以太坊网络在硬分叉之前强行执行EIP-155,这就说明ETHPoS链上交易不能在PoW链上重复交易。在正常的交易中,我们通过nonce来进行排序交易,避免重复交易。在跨链中,我们会根据chianid进行识别链的类型,比如以太坊主网的chainid是1,ETHW主网的chainid是10001。
对此,我们分析了OmniBridge相应的源码。我们查看一下OmniBridge验证chainid的逻辑,发现chainid的来源于unitStorage中存储的值,而不是通过操作码 CHAINID(0x46)直接读取的链上chainid。
unitStorage是合约EternalStorage中的状态变量,sourceChainId()函数所在的合约BasicAMB继承了BasicBridge和VersionableAMB。其中,BasicBridge陆续继承了合约EternalStorage。这里保存的chainid是预先存储好的,如果发生区块链的硬分叉而chainid又没有重新设置或者chainid人为设置有误,从合约层面上来说,由于不是通过操作码获取的chainid,不会正确验证跨链消息的实际chainid。这样的漏洞,容易被攻击者利用。
问题分析总结:主要是Omni使用的solidity版本是0.4.24,采用的是手动存储和更新chainid的方式,并未通过EIP-1344中规定的CHAINID(0x46)操作码进行实际chainid获取。
三、安全建议
引发本次安全事件的原因是在PoW升级PoS过程中,OmniBridge对chainid未及时处理。导致过旧的solidity版本中,存在历史遗留问题。建议在后续项目迭代中,及时应对新问题,采取必要的代码优化措施。虽然Gnosis链上OmniBridge有每日最大转移代币数量限制250个WETH,但是依旧要保持警惕,以防止积少成多,造成更大的损失。
关于我们:SharkTeam的愿景是全面保护Web3世界的安全。团队成员分布在北京、南京、苏州、硅谷,由来自世界各地的经验丰富的安全专业人士和高级研究人员组成,精通区块链和智能合约的底层理论,提供包括智能合约审计、链上分析、应急响应等服务。已与区块链生态系统各个领域的关键参与者,如OKC、polygon、Huobi Global、Polkadot、imToken、ChainIDE等建立长期合作关系。
Telegram:https://t.me/sharkteamorg
Twitter:https://twitter.com/sharkteamorg
更多区块链安全咨询与分析,点击下方链接查看
D查查|链上风险核查https://m.chainaegis.com