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

背景

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

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

0x 協(xié)議簡介

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

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

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

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

漏洞原理分析

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

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

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

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

2. 根據(jù)組裝的 ABI 編碼內(nèi)容計算簽名值正確性。

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

1. 引入 cdStart 指針，指向 calldata 中對應(yīng)的位置；

2. 對 WalletAddress 調(diào)用 staticcall（） OpCode 計算簽名正確性，

注意觀察代碼，其中的 input 和 output 都為 cdStart 這一指針，即復(fù)用 input/output 的內(nèi)存；

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

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

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

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

分別為：

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

2. 用戶為此訂單付出的 Token 數(shù)量；

3. Order 對應(yīng)的簽名信息 signature

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

漏洞影響分析

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

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

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

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

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

結(jié)語

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

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