SharkTeam:十大智能合约安全威胁之重放攻击
作者: 日期:2022年11月14日 阅:2,876

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

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

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

一、什么是重放攻击

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

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

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

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

二、攻击事件分析

2.1 Optimism

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

  • 月27日,Optimism地址0x2501向Optimism/L2上的0x4f3a地址转账2000万OP,0x4f3a地址在Ethereum/L1上是Wintermute的多签合约地址,但此时在Optimism/L2上面并没有部署合约;
  • 月1日,黑客地址0x8bcf部署合约0xe714。
  • 月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如下:
  • 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的合约。
  • 月5日,多签合约0x4f3a在接收到2000万OP后,将100万OP转账给黑客地址0x60b2,然后将100万OP兑换成了720.7 Ether。
  • 月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。

  • 链交易hash:0xbddb0cc8bc9949321e1748f03503ed1a20dd618fbf0a51dc5734c975b1f8bdf5
  • 链交易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)项目上线前,需联系专业的第三方专业审计团队进行审计。

申明:本文系厂商投稿收录,所涉观点不代表安全牛立场!


相关文章