一、事件描述

2022年9月18日，以太坊合并完成后，PoW链遭到PoS链上交易的重放攻击，根本原因是网桥未正确读取并验证区块链的chainid。攻击者首先通过Gnosis链的Omni跨链桥转移了200 WETH，然后在PoW链上重放了相同的消息，获得了额外的200 ETHW。

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