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

背景

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

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

0x 協(xié)議簡介

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

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

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

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

漏洞原理分析

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

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

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

1. 組裝簽名具體字段為 ABI 編碼格式；

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

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

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

2. 對 WalletAddress 調用 staticcall（） OpCode 計算簽名正確性，

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

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

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

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

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

分別為：

1. 代表訂單信息的 Order 類型；

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

3. Order 對應的簽名信息 signature

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

漏洞影響分析

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

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

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

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

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

結語

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

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