AIN:Cobo安全團隊：ETH硬分叉里的隱藏風險和套利機會_Hachiko Charity

原文作者：Cobo安全團隊

原文來源：CoboGlobal

ETH?升級?PoS?共識系統，原有的?PoW?機制的?ETH?鏈在部分社區的支持下成功硬分叉。但是，由于某些鏈上協議在設計之初沒有對可能的硬分叉做好準備，導致對應的協議在?ETHW?分叉鏈存在一定的安全隱患，其中最為嚴重的安全隱患則是重放攻擊。

在完成硬分叉后，?ETHW?主網出現了至少2起利用重放機制進行的攻擊，分別是?OmniBridge?的重放攻擊和?PolygonBridge?的重放攻擊。本文將以這兩個事件作為案例，分別分析重放攻擊對分叉鏈的影響，以及協議應如何防范此類攻擊。

交易重放

交易重放指的是將在原有鏈的交易原封不動的遷移到目標鏈的操作，屬于是交易層面上的重放，重放過后交易也是可以正常執行并完成交易驗證。最著名的案例莫過于?Wintermute?在?Optimism上的攻擊事件，直接導致了超2000萬OP代幣的損失。但是在?EIP155?實施以后，由于交易的簽名本身帶有?chainId?(一種用于鏈本身區別與其他分叉鏈的標識符)，在重放的目標鏈?chainId?不同的情況下，交易本身是無法完成重放的。

簽名消息重放

簽名消息重放區別于交易重放，是針對的用私鑰簽名的消息(e.g.?Coboisthebest)進行的重放，在簽名消息重放中，攻擊者不需要對整個交易進行重放，而只需將簽名的消息進行重放即可。在消息簽名中，以?Coboisthebest?為例，由于該消息中并不含任何和鏈相關的特殊參數，所以該消息在簽名后理論上是可以在任意的分叉鏈中均是有效的，可以驗簽通過。為了避免該消息在分叉上的重放，可以消息內容中添加?chainId，如?CoboisthebestchainId()。在帶上特定的鏈標識符之后，在不同分叉鏈上的消息內容不同，消息簽名不同，因此無法直接進行重放復用。

OmniBridge和PolygonBridge的攻擊原理

下面我們來分析?OmniBridge?和?PolygonBridge?的攻擊原理。首先拋出結論，這兩起攻擊事件本身都不是交易重放攻擊，原因在于?ETHW?使用了區別于?ETH?主網的?chainId，所以直接重放交易無法被驗證通過。那么剩下的選項就只有消息重放了，那下面我們就來逐個分析它們各自是如何在?ETHW?分叉鏈上被消息重放攻擊的。

跨鏈消息完成跨鏈接資產的轉移。在?OmniBridge?中，validator?提交的驗證消息的邏輯是這樣的

COBO VP：NFT當前賽道較為擁擠，但增長乏力:金色財經現場報道，COBO VP of Marketing Serena 在Coinlive和moledao主辦的線下活動上表示：NFT當前賽道較為擁擠，但增長乏力，從IP角度來說，集中于兩個方向：第一個是老IP的價值賦能，老酒裝新瓶，讓品牌可以吸引新的消費者流量；第二是，新IP的原生性，無論是新品牌，或是游戲或社交，新IP都需要用敘事去模式創新快速打造共識。

熊市中大家更應該將注意力放在場景和用戶的互動是否有真正的契合，以及在熊市去融資和小步快跑，同時注意鏈上資產存儲，底層合約安全。[2022/11/9 12:39:28]

function?executeSignatures(bytes?_data,?bytes?_signatures)?public?{????????_allowMessageExecution(_data,?_signatures);????????bytes32?msgId;????????address?sender;????????address?executor;????????uint32?gasLimit;????????uint8?dataType;????????uint256?memory?chainIds;????????bytes?memory?data;????????(msgId,?sender,?executor,?gasLimit,?dataType,?chainIds,?data)?=?ArbitraryMessage.unpackData(_data);????????_executeMessage(msgId,?sender,?executor,?gasLimit,?dataType,?chainIds,?data);????}

在這個函數中，首先會根據#L2行的簽名檢查來確定提交的簽名是不是由指定的?validator?進行簽名，然后再在#L11行對?data?消息進行解碼。從解碼內容上看，不難發現，返回字段中包含了?chainId?字段，那么是不是說明無法進行簽名消息重放呢？我們繼續分析。

function?_executeMessage(????????bytes32?msgId,????????address?sender,????????address?executor,????????uint32?gasLimit,????????uint8?dataType,????????uint256?memory?chainIds,????????bytes?memory?data????)?internal?{????????require(_isMessageVersionValid(msgId));????????require(_isDestinationChainIdValid(chainIds));????????require(!relayedMessages(msgId));????????setRelayedMessages(msgId,?true);????????processMessage(sender,?executor,?msgId,?gasLimit,?dataType,?chainIds,?data);????}

Cobo與冷兔達成合作，持有四周年NFT可獲得XRC白名單:1月7日消息，Cobo聯合創始人神魚發推宣布，Cobo與漫畫IP冷兔達成合作，持有Cobo四周年NFT的用戶可優先獲得由冷兔創作的XRC項目白名單。后續Cobo也將跟更多的優質的 NFT 項目合作，持續為四周年NFT進行賦能。

X Rabbits Club (XRC) 成立于 2012 年、全網粉絲超過6500萬。[2022/1/7 8:31:49]

通過追查?_executeMessage?函數，發現函數在#L11行對?chaindId?進行了合法性的檢查function?_isDestinationChainIdValid(uint256?_chainId)?internal?returns?(bool?res)?{

????????return?_chainId?==?sourceChainId();????}????function?sourceChainId()?public?view?returns?(uint256)?{????????return?uintStorage;????}

通過繼續分析后續的函數邏輯，不難發現其實針對?chainId?的檢查其實并沒有使用?evm?原生的?chainId?操作碼來獲取鏈本身的?chainId，而是直接使用存儲在?uintStorage?變量中的值，那這個值很明顯是管理員設置進去的，所以可以認為消息本身并不帶有鏈標識，那么理論上就是可以進行簽名消息重放的。

由于在硬分叉過程中，分叉前的所有狀態在兩條鏈上都會原封不動的保留，在后續?xDAI?團隊沒有額外操作的情況下。分叉后?ETHW?和?ETH?主網上?OmniBridge?合約的狀態是不會有變化的，也就是說合約的?validator?也是不會有變化的。根據這一個情況，我們就能推斷出?validator?在主網上的簽名也是可以在?ETHW?上完成驗證的。那么，由于簽名消息本身不包含?chainId，攻擊者就可以利用簽名重放，在?ETHW?上提取同一個合約的資產。

PolygonBridge

和?OmniBridge?一樣，PolygonBridge?是用于在?Polygon?和?ETH?主網進行資產轉移的橋。與?OmniBridge?不同，PolygonBridge?依賴區塊證明進行提款，邏輯如下：

function?exit(bytes?calldata?inputData)?external?override?{????????//...省略不重要邏輯????????//?verify?receipt?inclusion????????require(????????????MerklePatriciaProof.verify(????????????????receipt.toBytes(),????????????????branchMaskBytes,????????????????payload.getReceiptProof(),????????????????payload.getReceiptRoot()????????????),????????????"RootChainManager:?INVALID_PROOF"????????);????????//?verify?checkpoint?inclusion????????_checkBlockMembershipInCheckpoint(????????????payload.getBlockNumber(),????????????payload.getBlockTime(),????????????payload.getTxRoot(),????????????payload.getReceiptRoot(),????????????payload.getHeaderNumber(),????????????payload.getBlockProof()????????);????????ITokenPredicate(predicateAddress).exitTokens(????????????_msgSender(),????????????rootToken,????????????log.toRlpBytes()????????);????}

神魚預告Cobo將推出限量珍藏版NFT:12月13日，神魚在個人社交媒體平臺發布預告，Cobo將推出限量珍藏版NFT，全網限量1000份，白名單通道將于明天正式開啟。[2021/12/13 7:36:34]

通過函數邏輯，不難發現合約通過2個檢查確定消息的合法性，分別是通過檢查transactionRoot?和?BlockNumber?來確保交易真實發生在子鏈(PloygonChain)，第一個檢查其實可以繞過，因為任何人都可以通過交易數據來構造屬于自己的?transactionRoot，但是第二個檢查是無法繞過的，因為通過查看_checkBlockMembershipInCheckpoint邏輯可以發現：

function?_checkBlockMembershipInCheckpoint(????????uint256?blockNumber,????????uint256?blockTime,????????bytes32?txRoot,????????bytes32?receiptRoot,????????uint256?headerNumber,????????bytes?memory?blockProof????)?private?view?returns?(uint256)?{????????(????????????bytes32?headerRoot,????????????uint256?startBlock,????????????,????????????uint256?createdAt,????????)?=?_checkpointManager.headerBlocks(headerNumber);????????require(????????????keccak256(????????????????abi.encodePacked(blockNumber,?blockTime,?txRoot,?receiptRoot)????????????)????????????????.checkMembership(????????????????blockNumber.sub(startBlock),????????????????headerRoot,????????????????blockProof????????????),????????????"RootChainManager:?INVALID_HEADER"????????);????????return?createdAt;????}

對應的?headerRoot?是從?_checkpointManager?合約中提取的，順著這個邏輯我們查看?_checkpointManager設置?headerRoot?的地方

動態 | Pablo Escobar房地公司推出加密貨幣以彈劾特朗普:據The Next Web消息，已故梟Pablo Escobar的弟弟正在推出一項新的加密貨幣，試圖將美國總統唐納德?特朗普趕下臺。在GoFundMe為旗下的彈劾特朗普基金(彈劾特朗普基金)進行了5000萬美元的眾籌活動不到一天，Escobar Inc.就推出一種與美元掛鉤的穩定幣Escobar。[2019/1/12]

function?submitCheckpoint(bytes?calldata?data,?uint?calldata?sigs)?external?{????????(address?proposer,?uint256?start,?uint256?end,?bytes32?rootHash,?bytes32?accountHash,?uint256?_borChainID)?=?abi????????????.decode(data,?(address,?uint256,?uint256,?bytes32,?bytes32,?uint256));????????require(CHAINID?==?_borChainID,?"Invalid?bor?chain?id");????????require(_buildHeaderBlock(proposer,?start,?end,?rootHash),?"INCORRECT_HEADER_DATA");????????//?check?if?it?is?better?to?keep?it?in?local?storage?instead????????IStakeManager?stakeManager?=?IStakeManager(registry.getStakeManagerAddress());????????uint256?_reward?=?stakeManager.checkSignatures(????????????end.sub(start).add(1),????????????/**??????????????????prefix?01?to?data?????????????????01?represents?positive?vote?on?data?and?00?is?negative?vote????????????????malicious?validator?can?try?to?send?2/3?on?negative?vote?so?01?is?appended?????????????*/????????????keccak256(abi.encodePacked(bytes(hex"01"),?data)),????????????accountHash,????????????proposer,????????????sigs????????);//....剩余邏輯省略

聲音 | 眼鏡蛇Cobra：6個月內BCH將會分叉:眼鏡蛇Cobra在推特中表示，因為提前共識（pre-consensus）的矛盾，6個月內BCH將會分叉。[2018/8/8]

不難發現在#L2行代碼中，簽名數據僅對?borChianId?進行了檢查，而沒有對鏈本身的?chainId?進行檢查，由于該消息是由合約指定的?proposer?進行簽名的，那么理論上攻擊者也可以在分叉鏈上重放?proposer?的消息簽名，提交合法的?headerRoot，后續再通過?PolygonBridge進行在?ETHW鏈中調用?exit?函數并提交相應的交易?merkleproof?后就可以提現成功并通過?headerRoot?的檢查。

以地址0x7dbf18f679fa07d943613193e347ca72ef4642b9為例，該地址就成功通過以下幾步操作完成了對?ETHW?鏈的套利

首先依靠鈔能力主網交易所提幣。

在?Ploygon?鏈上通過?PolygonBridge?的?depositFor?函數進行充幣；

ETH?主網調用?PolygonBridge?的?exit?函數提幣；

復制提取?ETH?主網?proposer?提交的?headerRoot；

在?ETHW?中重放上一步提取的?proposer?的簽名消息；

在?ETHW?中的?PolygonBridge?上調用?exit?進行提幣

為什么會發生這種情況？

從上面分析的兩個例子中，不難發現這兩個協議在?ETHW?上遭遇重放攻擊是因為協議本身沒有做好防重放的保護，導致協議對應的資產在分叉鏈上被掏空。但是由于這兩個橋本身并不支持?ETHW?分叉鏈，所以用戶并沒有遭受任何損失。但我們要考慮的事情是為什么這兩個橋在設計之初就沒有加入重放保護的措施呢？其實原因很簡單，因為無論是?OmniBridge?還是?PolygonBridge，他們設計的應用場景都非常單一，只是用于到自己指定的對應鏈上進行資產轉移，并沒有一個多鏈部署的計劃，所以沒有重放保護而言對協議本身并不造成安全影響。

反觀?ETHW?上的用戶，由于這些橋本身并不支持多鏈場景，如果用戶在?ETHW?分叉鏈上進行操作的話，反而會在?ETH?主網上遭受消息重放攻擊。

以?UniswapV2?為例，目前在?UnswapV2?的?pool?合約中，存在?permit?函數，該函數中存在變量?PERMIT_TYPEHASH，其中包含變量?DOMAIN_SEPARATOR。

function?permit(address?owner,?address?spender,?uint?value,?uint?deadline,?uint8?v,?bytes32?r,?bytes32?s)?external?{????????require(deadline?>=?block.timestamp,?'UniswapV2:?EXPIRED');????????bytes32?digest?=?keccak256(????????????abi.encodePacked(????????????????'\x19\x01',????????????????DOMAIN_SEPARATOR,????????????????keccak256(abi.encode(PERMIT_TYPEHASH,?owner,?spender,?value,?nonces,?deadline))????????????)????????);????????address?recoveredAddress?=?ecrecover(digest,?v,?r,?s);????????require(recoveredAddress?!=?address(0)?&&?recoveredAddress?==?owner,?'UniswapV2:?INVALID_SIGNATURE');????????_approve(owner,?spender,?value);????}

此變量最早在?EIP712?中定義，該變量中含有?chainId，在設計之初就包含可能的多鏈場景的重放預防，但是根據?uniswapV2pool?合約的邏輯，如下：

constructor()?public?{???????uint?chainId;???????assembly?{???????????chainId?:=?chainid???????}???????DOMAIN_SEPARATOR?=?keccak256(???????????abi.encode(???????????????keccak256('EIP712Domain(string?name,string?version,uint256?chainId,address?verifyingContract)'),???????????????keccak256(bytes(name)),???????????????keccak256(bytes('1')),???????????????chainId,???????????????address(this)???????????)???????);???}

DOMAIN_SEPARATOR?在構造函數中已經定義好，也就是說在硬分叉后，就算鏈本身的?chainId?已經改變，pool?合約也無法獲取到新的?chianId?來更新?DOMAIN_SEPARATOR，如果未來用戶在?ETHW上進行相關授權，那么ETHW上的?permit?簽名授權可以被重放到?ETH?主網上。除了?Uniswap?外，類似的協議還有很多，比如特定版本下的?yearnvault合約，同樣也是采用了固定?DOMAIN_SEPARATOR?的情況。用戶在?ETHW?上交互的時候也需要防范此類協議的重放風險。

開發者而言，在為協議本身定制消息簽名機制的時候，應該考慮后續可能的多鏈場景，如果路線圖中存在多鏈部署的可能，應該把?chainId?作為變量加入到簽名消息中，同時，在驗證簽名的時候，由于硬分叉不會改變分叉前的任何狀態，用于驗證簽名消息的?chainId不應該設置為合約變量，而應該在每次驗證前重新獲取，然后進行驗簽，保證安全性。對用戶的影響

普通在協議不支持分叉鏈的情況下，應盡量不在分叉鏈上進行任何操作，防止對應的簽名消息重放到主網上，造成用戶在主網上損失資產

總結

隨著多鏈場景的發展，重放攻擊從理論層面逐步變成主流的攻擊方式，開發者應當仔細考量協議設計，在進行消息簽名機制的設計時，盡可能的加入?chainId?等因子作為簽名內容，并遵循相關的最佳實踐，防止用戶資產的損失。

Tags：AINHAICHAChainquarkchain幣發行人culturechainHachiko Charitychainlink幣

芝麻開門交易所