SharkTeam:十大智能合约安全威胁之重放攻击

  • SharkTeam
  • 更新于 2022-11-10 20:17
  • 阅读 2631

第十课【详解重放攻击】。

问:我们常提到的智能合约漏洞真的是实际中威胁最大、发生最频繁的安全漏洞吗? 答:完全不是那样。例如“溢出”、“外部调用”等常提到的智能合约安全漏洞并不是最常发生,威胁最大的。 到底哪些安全威胁从发生频率和危害性上能称为Top10的呢?SharkTeam合约安全系列课程之【十大智能合约安全威胁】和您一起讨论和深入。第十课【详解重放攻击】。

image.png

一、什么是重放攻击

重放攻击是把原链网络上的交易拿到目标链网络上使用,即一笔交易重复执行,我们根据类型可以分为交易重放和签名重放。 交易重放是将原链上的交易一成不变放到目标链上,重放过后交易在目标链上可以正常执行并完成交易验证。 签名重放利用私钥签名的消息进行重放,重放过程中无需像交易重放那样去重放整个交易,而是重放相应的签名信息。 在实施EIP 155后,交易签名带有chainid,即链与分叉链之间的标识符。由于chainid不同,交易重放无法完成,签名重放可以间接完成。在以太坊完成分叉后,ETHW主网出现数起重放攻击事件,让我们回顾一下这些攻击事件前因后果。

二、攻击事件分析

2.1 Optimism

2022年6月9日消息,据Optimism与加密货币做市商 Wintermute 透露,2000万个Optimism代币被黑客盗取。重放攻击过程如下: (1)5月27日,Optimism地址0x2501向Optimism/L2上的0x4f3a地址转账2000万OP,0x4f3a地址在Ethereum/L1上是Wintermute的多签合约地址,但此时在Optimism/L2上面并没有部署合约; (2)6月1日,黑客地址0x8bcf部署合约0xe714。 (3)6月5日,黑客通过重放Ethereum/L1上的交易创建了Gnosis Safe: Proxy Factory 1.1.1合约,其地址与Ethereum/L1上一样;然后地址0x60b2通过合约0xe714部署了多签合约0x4f3a,合约所有权归黑客所有,因此5月27日转入的2000万OP被黑客盗取。在Gnosis Safe: Proxy Factory 1.1.1合约中,其中创建代理合约函数createProxy如下:

image.png Gnosis Safe: Proxy Factory 1.1.1合约使用的是0.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的合约。 (4)6月5日,多签合约0x4f3a在接收到2000万OP后,将100万OP转账给黑客地址0x60b2,然后将100万OP兑换成了720.7 Ether。 (5)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。 (1)PoS链交易hash:0xbddb0cc8bc9949321e1748f03503ed1a20dd618fbf0a51dc5734c975b1f8bdf5 (2)PoW链交易hash:0x9c072551861ce384203516f4d705176a2d2e262d5b571d853467425f1a861fb4 我们对比发现两笔交易访问的合约相同,并且inputdata完全相同,即调用了同一个合约的同一个函数并且参数相同,根据相同的方法签名ID 0x23caab49可知,黑客调用safeExecuteSignaturesWithAutoGasLimit函数。

image.png 在正常的交易中,我们通过nonce来进行排序交易,避免重复交易。在跨链中,我们会根据chianid进行识别链的类型,比如以太坊主网的chainid是1,ETHW主网的chainid是10001。 我们查看一下Omni Bridge验证chainid的逻辑,发现chainid的来源于unitStorage中存储的值,而不是通过操作码 CHAINID(0x46)直接读取的链上chainid。

image.png unitStorage是合约EternalStorage中的状态变量,sourceChainId()函数所在的合约BasicAMB继承了BasicBridge和VersionableAMB。其中,BasicBridge陆续继承了合约EternalStorage。这里保存的chainid是预先存储好的,如果发生区块链的硬分叉而chainid又没有重新设置或者chainid人为设置有误,从合约层面上来说,由于不是通过操作码获取的chainid,不会正确验证跨链消息的实际chainid。 本次攻击根本原因是:主要是Omni使用的solidity版本是0.4.24,采用的是手动存储和更新chainid的方式,并未通过EIP-1344中规定的CHAINID(0x46)操作码进行实际chainid获取。

三、预防措施

针对重放攻击主要有以下几种预防的方法: (1)可以在签名消息中加入chainid和nonce两个参数值,chainid用于识别链ID的标识符,nonce是交易次数计数值。 (2)记录签名是否使用过,比如利用mapping进行签名中对应参数映射为bool值,这样做可以防止签名多次使用。 (3)项目上线前,需联系专业的第三方专业审计团队进行审计。 关于我们:SharkTeam的愿景是全面保护Web3世界的安全。团队成员分布在北京、南京、苏州、硅谷,由来自世界各地的经验丰富的安全专业人士和高级研究人员组成,精通区块链和智能合约的底层理论,提供包括智能合约审计、链上分析、应急响应等服务。已与区块链生态系统各个领域的关键参与者,如Polkadot、Moonbeam、polygon、OKC、Huobi Global、imToken、ChainIDE等建立长期合作关系。

image.png Twitter:https://twitter.com/sharkteamorg Discord:https://discord.gg/jGH9xXCjDZ
Telegram:https://t.me/sharkteamorg 更多区块链安全咨询与分析,点击下方链接查看 D查查|链上风险核查 https://m.chainaegis.com

点赞 0
收藏 2
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。
该文章收录于 智能合约安全
426 订阅 172 篇文章

0 条评论

请先 登录 后评论
SharkTeam
SharkTeam
0xC0f5...8888
SharkTeam是领先的Web3安全服务提供商,提供智能合约审计、链上分析和应急响应服务。 Web: https://www.sharkteam.org Telegram: https://t.me/sharkteamorg Twitter:https://twitter.com/sharkteamorg