重放攻擊是把原鍊網絡上的交易拿到目標鍊網絡上使用
問：我們常提到的智能合約漏洞真的是實際中威脅最大、發生最頻繁的安全漏洞嗎？
答：完全不是那樣。例如“溢出”、“外部調用”等常提到的智能合約安全漏洞並不是最常發生，威脅最大的。
到底哪些安全威脅從發生頻率和危害性上能稱為Top10的呢？ SharkTeam合約安全系列課程之【十大智能合約安全威脅】和您一起討論和深入。第十課【詳解重放攻擊】。
一、什麼是重放攻擊
重放攻擊是把原鍊網絡上的交易拿到目標鍊網絡上使用，即一筆交易重複執行，我們根據類型可以分為交易重放和簽名重放。
交易重放是將原鏈上的交易一成不變放到目標鏈上，重放過後交易在目標鏈上可以正常執行並完成交易驗證。
簽名重放利用私鑰簽名的消息進行重放，重放過程中無需像交易重放那樣去重放整個交易，而是重放相應的簽名信息。
在實施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如下：
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函數。
在正常的交易中，我們通過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獲取。
三、預防措施
針對重放攻擊主要有以下幾種預防的方法：
（1）可以在簽名消息中加入chainid和nonce兩個參數值，chainid用於識別鏈ID的標識符，nonce是交易次數計數值。
（2）記錄簽名是否使用過，比如利用mapping進行簽名中對應參數映射為bool值，這樣做可以防止簽名多次使用。
（3）項目上線前，需聯繫專業的第三方專業審計團隊進行審計。
來源：tuoniaox