问：我们常提到的智能合约漏洞真的是实际中威胁最大、发生最频繁的安全漏洞吗？

答：完全不是那样。例如“溢出”、“外部调用”等常提到的智能合约安全漏洞并不是最常发生，威胁最大的。

到底哪些安全威胁从发生频率和危害性上能称为Top10的呢？SharkTeam合约安全系列课程之【十大智能合约安全威胁】和您一起讨论和深入。第十课【详解重放攻击】。

一、什么是重放攻击

重放攻击是把原链网络上的交易拿到目标链网络上使用，即一笔交易重复执行，我们根据类型可以分为交易重放和签名重放。

交易重放是将原链上的交易一成不变放到目标链上，重放过后交易在目标链上可以正常执行并完成交易验证。

签名重放利用私钥签名的消息进行重放，重放过程中无需像交易重放那样去重放整个交易，而是重放相应的签名信息。

在实施EIP 155后，交易签名带有chainid，即链与分叉链之间的标识符。由于chainid不同，交易重放无法完成，签名重放可以间接完成。在以太坊完成分叉后，ETHW主网出现数起重放攻击事件，让我们回顾一下这些攻击事件前因后果。

二、攻击事件分析

2.1 Optimism

2022年6月9日消息，据Optimism与加密货币做市商 Wintermute 透露，2000万个Optimism代币被黑客盗取。重放攻击过程如下：

• 5月27日，Optimism地址0x2501向Optimism/L2上的0x4f3a地址转账2000万OP，0x4f3a地址在Ethereum/L1上是Wintermute的多签合约地址，但此时在Optimism/L2上面并没有部署合约；
• 6月1日，黑客地址0x8bcf部署合约0xe714。
• 6月5日，黑客通过重放Ethereum/L1上的交易创建了Gnosis Safe: Proxy Factory 1.1.1合约，其地址与Ethereum/L1上一样；然后地址0x60b2通过合约0xe714部署了多签合约0x4f3a，合约所有权归黑客所有，因此5月27日转入的2000万OP被黑客盗取。在GnosisSafe: Proxy Factory 1.1.1合约中，其中创建代理合约函数createProxy如下：

• Gnosis Safe: Proxy Factory 1.1.1合约使用的是5版本的Solidity，使用new来创建合约时使用的是create命令，而不是create2。使用create命令创建合约，合约地址是msg.sender以及nonce来计算的。在Ethereum/L1上面，创建多签合约0x4f3a的msg.sender就是Gnosis Safe: Proxy Factory 1.1.1的地址，黑客在Optimism/L2通过重放交易来创建于Gnosis Safe: Proxy Factory 1.1.1合约的主要目的就是为了保证在Optimism/L2上创建合约0x4f3a的msg.sender与在Ethereum/L1上一致，那么黑客可以很方便的通过智能合约（合约0xe714）调用createProxy函数来创建出地址是0x4f3a的合约。
• 6月5日，多签合约0x4f3a在接收到2000万OP后，将100万OP转账给黑客地址0x60b2，然后将100万OP兑换成了7 Ether。
• 6月9日，合约0x4f3a将其中的100万OP转账给了账户地址0xd8da， 其他的1800万OP仍然在合约0x4f3a中。

本次攻击根本原因是：交易重放、Solidity旧版本漏洞以及主链和侧链交易签名验证等综合因素

2.2 Omni

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

• PoS链交易hash：0xbddb0cc8bc9949321e1748f03503ed1a20dd618fbf0a51dc5734c975b1f8bdf5
• PoW链交易hash：0x9c072551861ce384203516f4d705176a2d2e262d5b571d853467425f1a861fb4

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

在正常的交易中，我们通过nonce来进行排序交易，避免重复交易。在跨链中，我们会根据chianid进行识别链的类型，比如以太坊主网的chainid是1，ETHW主网的chainid是10001。

我们查看一下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获取。

三、预防措施

针对重放攻击主要有以下几种预防的方法：

• 可以在签名消息中加入chainid和nonce两个参数值，chainid用于识别链ID的标识符，nonce是交易次数计数值。
• 记录签名是否使用过，比如利用mapping进行签名中对应参数映射为bool值，这样做可以防止签名多次使用。

（3）项目上线前，需联系专业的第三方专业审计团队进行审计。

关于我们：SharkTeam的愿景是全面保护Web3世界的安全。团队成员分布在北京、南京、苏州、硅谷，由来自世界各地的经验丰富的安全专业人士和高级研究人员组成，精通区块链和智能合约的底层理论，提供包括智能合约审计、链上分析、应急响应等服务。已与区块链生态系统各个领域的关键参与者,如Polkadot、Moonbeam、polygon、OKC、Huobi Global、imToken、ChainIDE等建立长期合作关系。

Twitter：https://twitter.com/sharkteamorg

Discord：https://discord.gg/jGH9xXCjDZ

Telegram：https://t.me/sharkteamorg

更多区块链安全咨询与分析，点击下方链接查看

D查查|链上风险核查 https://m.chainaegis.com