警惕以太坊合并后的重放攻击：Omni跨链桥被攻击事件分析

SharkTeam 刚刚

二、事件分析

该事件涉及两个不同链的交易hash以及攻击者地址，分别如下：

（1）PoS链交易hash：0xbddb0cc8bc9949321e1748f03503ed1a20dd618fbf0a51dc5734c975b1f8bdf5

（2）PoW链交易hash：0x9c072551861ce384203516f4d705176a2d2e262d5b571d853467425f1a861fb4

（3）攻击者地址：0x82FaEd2dA812D2E5CCed3C12b3baeB1a522DC677

首先，我们对比发现两笔交易访问的合约相同，并且inputdata完全相同，即调用了同一个合约的同一个函数并且参数相同，根据相同的方法签名ID 0x23caab49可知，黑客调用safeExecuteSignaturesWithAutoGasLimit函数。

因此，攻击者通过Omni Bridge 转移200WETH，然后在PoW链上重放了相同的Inputdata，获得了额外的200 ETHW。

此时，我们对这里的重放操作抱有怀疑态度。因为，以太坊网络在硬分叉之前强行执行EIP-155，这就说明ETH PoS链上交易不能在PoW链上重复交易。在正常的交易中，我们通过nonce来进行排序交易，避免重复交易。在跨链中，我们会根据chianid进行识别链的类型，比如以太坊主网的chainid是1，ETHW主网的chainid是10001。

对此，我们分析了Omni Bridge相应的源码。我们查看一下Omni Bridge验证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过程中，Omni Bridge对chainid未及时处理。导致过旧的solidity版本中，存在历史遗留问题。建议在后续项目迭代中，及时应对新问题，采取必要的代码优化措施。虽然Gnosis 链上Omni Bridge有每日最大转移代币数量限制250个WETH，但是依旧要保持警惕，以防止积少成多，造成更大的损失。

推荐阅读