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

原文作者：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運營負責人車向陽加入BiKi并擔任BiKi Ventures合伙人:據官方消息，前Cobo運營負責人車向陽Eminem于今日正式加入BiKi，擔任BiKi Ventures合伙人，主要負責基金投資業務，助力BiKi生態產業鏈建設。

BiKi Ventures是BiKi平臺最新成立的風險投資基金，首期規模500萬美金，將定向投資以太坊和波卡等生態內優質項目，推進Web3.0時代的加速落地，目前已投資多個項目。車向陽Eminem加入BiKi前，曾在360、映客直播等互聯網公司負責產品業務，后在Cobo擔任運營負責人，積累了豐富的互聯網和區塊鏈產品運營經驗。[2020/12/31 16:09:52]

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 Custody與Chainalysis達成戰略合作:企業級數字錢包開發及資產托管服務平臺Cobo Custody宣布與區塊鏈交易監控服務商Chainalysis達成戰略合作，Chainalysis將為Cobo Custody及其合作的200多家客戶提供安全合規服務，檢測和監控洗錢、欺詐等違法行為，降低合規風險。此次合作意味著Cobo Custody成為Chainalysis服務的首批亞洲客戶，在安全合規的道路上又邁出了重要的一步。

Chainalysis區塊鏈交易監控工具服務商，為全球40多個國家的政府機構、交易所以及金融機構提供區塊鏈數據分析和交易監控解決方案，同時也幫助客戶發現數字貨幣的可疑活動，以打擊相關犯罪活動。

Cobo Custody是面向全球機構客戶與合格投資者的錢包開發及數字資產托管服務，以高安全級的HSM加密機、多重簽名及冷熱分離存儲為安全保障基礎，已服務于交易所、錢包、資管平臺等200多家機構客戶。[2020/9/15]

通過追查?_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?上提取同一個合約的資產。

Cobra：運行非核心全節點軟件是讓BTC更具彈性的最好方式:Bitcoin.org網站共同所有者Cobra剛剛發推稱，應該有更多的人運行非核心的全節點軟件，這確實是讓比特幣更具彈性的最好方式。共識分裂的風險和影響被夸大了，而實質上每個比特幣節點容易受到相同漏洞威脅的風險要更大。[2020/8/24]

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：分布式節點網絡將取代中心化交易所:Cobra剛剛在其社交媒體稱，中心化交易所將在未來五年內成為過去時。他們將被分布式的節點網絡取代，這些節點將促進不同加密貨幣間的去信任原子交換。法幣將通過美元支持的穩定幣進入這種分布式的節點網絡。[2018/9/13]

對應的?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????????);//....剩余邏輯省略

不難發現在#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：AINHAIChainCHAGAINZ TOKENSkychainIndexChainInfChain

Filecoin