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

原文作者：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宣布已獲得美國MSB牌照，2022將推動DeFi合規:據官方消息，亞太加密貨幣托管服務商Cobo積極與監管對話，推動Defi業務合規，Cobo始終積極擁抱合規，其中香港TCSP牌照于2019年獲得并已提交牌照續展申請，并續展美國FinCEN頒發的MSB牌照，公布持牌編號“31000197415541”。自去年10月冷啟動DeFi基金業務后，自營DeFi基金TVL8.31億美金，是目前亞太最大的機構DeFi資管產品。[2022/2/15 9:53:06]

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);????}

Cobra：比特幣達到10萬美元以上至少還需幾年時間:Bitcoin.org網站共同所有者Cobra今日發推文稱：“今年早些時候，當我說下一個泡沫的頂部將在3萬美元左右時，人們稱我為看跌者，但看起來我是相當準確的。我不相信人們真的相信比特幣會在這個周期達到10萬美元以上。這至少還需要幾年的時間。”[2020/12/5 14:04:46]

通過追查?_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宣布支持MDU Staking服務:Cobo錢包宣布成為MDU Staking計劃主要節點之一，全面支持MDU的充提及Staking服務。

MDUKEY是一個自我主權隱私數據系統，通過區塊鏈技術將隱私、安全性、透明度和個人權利轉變為數字身份，相應的密鑰保存在數字錢包中。

Cobo錢包致力于打造一站式數字資產存儲和管理平臺，旨在為用戶提供安全、可靠的存儲與支付環境，目前已支持40多種主流數字資產、900多種代幣。[2020/6/2]

通過函數邏輯，不難發現合約通過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;????}

聲音 | 眼鏡蛇Cobra：建議貝索斯使用BTC:針對亞馬遜CEO 杰夫貝索斯(Jeff Bezos)與其妻子離婚一事，比特幣官方論壇Bitcoin.org持有人眼鏡蛇在推特上表示，使用比特幣， 你的配偶無法通過離婚拿走你的半數資產。[2019/1/10]

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

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：加密行業需少些部落主義 多些合作精神:Satoshi Portal首席執行官Francis Pouliot日前在推特發布關于“反BCH最有影響力的100人”推文，眼鏡蛇Cobra轉發其推文并評論稱：如果社會上有很大一部分人把對一項技術的非理性仇恨看作是一種榮譽的象征，這個行業就注定要滅亡。比特幣現金只是一種可以讓安全權衡助力零售和支付用例的山寨幣，僅此而已。請少些部落主義，多些合作精神。[2018/10/29]

不難發現在#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：AINChainCHAHAIsimplechainBinance Multi-Chain CapitalSchain Walletplugchain幣是那國發行的

POL幣最新價格