0x協議漏洞原理剖析：惡意掛單可擾亂正常交易秩序

?昨天，去中心化交易所協議 0x 項目方稱其發現嚴重安全漏洞。PeckShield 安全人員跟進分析發現，0x Exchange 合約在校驗訂單簽名時存在缺陷，導致攻擊者可以進行惡意掛單，進而將用戶的數字資產低價賣出，擾亂正常的交易秩序。所幸項目方及時發現並修復問題，截至目前，尚未有真實攻擊發生，並沒有產生數字資產損失。

背景

北京時間2019年07月13日，去中心化交易所 0x 協議項目方稱其發現嚴重安全漏洞，並緊急關閉了 0x Exchange v2.0 合約，隨後部署了修復後的合約。受此影響，基於 0x 協議的交易所及錢包，包括 Radar Relay，Tokenlon, Star Bit 等緊急暫停了相關交易服務。

PeckShield 安全人員跟進分析發現，0x Exchange 合約在校驗訂單簽名時存在缺陷，導致攻擊者可以進行惡意掛單，進而將用戶的數字資產低價賣出，擾亂正常的交易秩序。

0x 協議簡介

0x 協議是一個基於以太坊的開放協議，實現鏈上資產的點對點交易。它期望在以太坊上創建一種標準協議，使得任何人能夠基於此協議運行去中心化交易所，實現以太坊上的代幣之間的交易。0x 協議上的交易特點是鏈下訂單撮合，鏈上結算，其中為用戶交易提供訂單服務的參與者稱為中繼者。0x 項目發行了自己的代幣 ZRX，一方面作為去中心化治理投票權的證明，同時也被作為交易服務費，用於建立在 0x 協議之上的中繼者提供服務的收益。

0x 協議受到不少去中心化交易所和錢包的青睞，從 Etherscan 的 DEX 過去七天交易份額的餅圖中能看到，排名靠前的 Radar Relay 和 Tokenlon 都是基於 0x 協議：

另外，從 DAppTotal 的 DEX 24小時交易額排名中也能看到它們的排名：

由於 Ethereum 平台上大量的 DEX 都使用了 0x 協議，而作為最根本的 Token Tranfer 主合約出問題，這對於整個 DEX 領域來說，都是比較重大的事件。

漏洞原理分析

本次漏洞共涉及 isValidWalletSignature() 和 ?isValidValidatorSignature() 兩個相似的漏洞，由於兩者出問題的代碼是相似的，本文只以前者為例說明。

isValidWalletSignature(bytes32, address, bytes) 函數用於驗證給定的 Wallet 合約所定義的簽名信息與給定的簽名是否一致，用於確保 Order 是由正確的 Maker/Taker 執行的交易。但是 0x Exchange 合約在驗證的過程中，存在著比較嚴重的問題：

上圖是這一函數的全部邏輯，分為兩部分：

組裝簽名具體欄位為 ABI 編碼格式；

根據組裝的 ABI 編碼內容計算簽名值正確性。

其中，第 2 步的邏輯，在 0x v2 合約代碼中是用彙編實現的:

引入 cdStart 指針，指向 calldata 中對應的位置；

對 WalletAddress 調用 staticcall() OpCode 計算簽名正確性，

注意觀察代碼，其中的 input 和 output 都為?cdStart?這一指針，即復用 input/output 的內存；

檢驗步驟 2.2 中的結果是否正確。

WalletAddress 為合約的前提下，這樣子的流程沒有問題。先來看下 EVM 中合約的執行流程是怎樣的，PeckShield 安全人員查閱 EVM 源碼的時候發現：

當被調用的合約（即這裡的 WalletAddress ）沒有 code, 也就是 EOA 賬號的情況下，什麼都沒有的執行，直接返回。因此，對應到 isValidWalletSignature(bytes32, address, bytes) 函數來說，其中的 cdStart 所對應的內存內容在調用 staticcall() 前後並沒有變化，而後面在判斷簽名是否正確的 isValid 取值的時候，也就取到了錯誤的值。

用戶通過 fillOrder(Order, uint256, bytes) 函數完成 Token 買賣，PeckShield 安全人員發現，這一函數的三個參數可以由用戶自由配置：

分別為：

代表訂單信息的 Order 類型；

用戶為此訂單付出的 Token 數量；

Order 對應的簽名信息 signature

其中比較關鍵的是?Order?及對應的 signature 信息的一致性正是通過上面的?isValidWalletSignature()?類函數校驗，因此，當攻擊者精心構造 signature 為?SignatureTypeWallet?時，可『跳過』簽名合法性檢查，從而使得用戶在不經意之間被惡意掛單（甚至是低價掛單），從而被攻擊者順利吃單，由於這一訂單信息是由攻擊者直接傳入合約的，因此這一訂單信息在線下的中繼者也無法查詢。

漏洞影響分析

基於上述分析發現，曾在 0x 協議 Exchange 上做過授權轉賬的普通用戶帳號都將受到影響：

攻擊者可偽造用戶掛單，低價獲得用戶代幣。

鑒於此安全漏洞的危害性，PeckShield 安全人員發現 0x 項目方在漏洞被發現的時候先緊急關閉了 0x Exchange v2.0 合約的 Token transfer 功能，將所有的 ERC20、ERC721、以及 MultiAsset 的 Transfer ?功能全部下線；隨後部署了修復後的合約，同時告知用戶及使用了 0x Exchange 的所有 DEX 及 Relayer，相關的遷移升級工作正在進行中。受此影響，基於 0x 協議的交易所及錢包，包括 Radar Relay, Tokenlon, Star Bit 等緊急暫停了交易服務。

PeckShield 安全人員通過漏洞特性分析鏈上數據發現，從 0x Exchange 2018-09 上線至今，並沒有因此安全漏洞造成的用戶直接資產損失。

對於使用了 0x 的 DEX 及錢包來說，當前的階段需要暫停交易服務，如無法暫停交易服務的話，可將對應的 0x Exchange 合約地址變更為當前已經修復的合約地址。

結語

0x 協議本次出現漏洞的合約代碼，主要是內聯彙編代碼編寫簽名驗證功能出現的問題，直接編寫彙編代碼雖然在編譯器無法優化合約代碼的情況下非常有用，可控性更強且能提高執行效率，減少 Gas 消耗，但是編寫 Solidity 彙編代碼需要對 EVM 運行機制有非常熟悉的理解，不然 EVM 的某些特性可能導致編寫的合約無法正常運行，同時也缺少了 Solidity 提供的多種安全機制。

PeckShield 安全人員在此提醒廣大開發者及時排查合約的相關代碼，避免類似問題可能造成的安全風險，對於 DEX 等 DeFi 類項目，項目方在上線前需要找有資質的安全公司審計安全風險。

（作者：PeckShield，內容來自鏈得得內容開放平台「得得號」；本文僅代表作者觀點，不代表鏈得得官方立場）

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！