基于以太坊的開放協(xié)議0x項(xiàng)目發(fā)生了嚴(yán)重的安全漏洞

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

背景

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

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

0x 協(xié)議簡(jiǎn)介

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

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

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

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

漏洞原理分析

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

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

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

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

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

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

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

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

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

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

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

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

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

分別為：

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

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

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

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

漏洞影響分析

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

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

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

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

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

結(jié)語

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

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