2019 年 09 月 13 日 AirSwap 團隊公布了一個 AirSwap 智能合約中存在致命的漏洞，這一漏洞可以使得用戶的資產在某些情況下被對手惡意吃單『偷盜
2019 年 09 月 13 日 AirSwap 團隊公布了一個 AirSwap 智能合約中存在致命的漏洞，這一漏洞可以使得用戶的資產在某些情況下被對手惡意吃單『偷盜』，PeckShield 安全人員獨立分析了該漏洞，并與 AirSwap 團隊溝通了細節和修復方案。
漏洞影響概述
PeckShield 安全人員深入分析 AirSwap 智能合約后發現，這一漏洞只對最近上線的 Wrapper 有影響，AirSwap 團隊在發現該問題后第一時間下線當前合約，并將 AirSwap 網站回退到之前使用的合約，從合約上線到問題修復整個過程僅持續了 24 小時，可見 AirSwap 團隊對于合約安全的重視程度之高。
PeckShield 安全人員獨立分析了漏洞細節，并與 AirSwap 團隊溝通細節和修復的方案， 同時將該漏洞命名為“ItchySwap”。
PeckShield 在此提醒，由于這一漏洞可使用戶的資產被攻擊者惡意偷盜，受此次影響的賬號一共有 18 個，其中有部分賬號有數萬至數十萬美元的資產，這些賬號需要盡快完成升級，或與 AirSwap 團隊聯系。
ItchySwap 漏洞詳解
一、AirSwap 合約
在分析之前，為方便起見，我們先定義幾個概念：
1. maker：出售資產的一方;
2. taker：購買資產的一方;
3. order: maker 與 taker 之間發生資產交割的訂單;
4. Indexer: AirSwap 中的訂單簿，匯聚了當前正在出售及需要購買的資產信息。
下圖說明了 maker、taker 和 Indexer 之間的交互流程：
**
**
AirSwap 是一個基于 Ethereum 的點對點去中心化交易所，它集成了 Swap Protocol ，在其中作為一個自動托管服務，允許交易的雙方(即 maker 和 taker)在以太坊上安全地交易任何資產。與許多去中心化交易所不同，AirSwap 雖然沒有對資金進行托管控制，但仍然有一個用于匹配目的的集中式訂單簿，它實現了一個用于交易和訂單匹配的完全對等模型。
特別值得一提的是，有一個名為 Indexer 的鏈下服務，可以聚合來自 maker 和 taker 的交易意圖，然后為他們提供匹配的服務。特別是，一旦 taker 找到了合適的 maker，他們就會開始進行場外價格的談判。一旦達成協議，訂單將由 Taker 通過 Swap Protocol 在鏈上進行填充和資產交割。
在 AirSwap 智能合約中， taker 將訂單上鏈及資產交割的過程在 AirSwap swap(Types.Order calldata_order) 函數之中，這一函數實現如下所示：
1)驗證訂單有效性
訂單 order 參數有效性檢查，這些信息均由 taker 上鏈的時候指定的，也意味著這些信息都可以由 taker 篡改，具體包含：
1. 訂單還在有效期內;
2. 訂單還沒有被其它的 taker 吃單;
3. 訂單還沒有被取消;
4. 訂單的 nonce 大于最小值;
5. 設置訂單狀態為 TAKEN 狀態。
2)驗證 taker 信息
確立有效的 taker，根據 order 中指定或者等同于合約的調用方 msg.sender。
3)驗證 maker 信息
驗證 maker 的有效性，這里的驗證分為兩種情況考慮：
1. 沒有 maker 簽名的訂單：需要保證 msg.sender 有權限操作這個 maker 地址即可，即這筆 order 發起者有權限操作 maker 的資產;
2. order 中指定了 maker 的簽名信息：驗證簽名的有效性。
4) 資產交割**
**
如果上述的驗證流程沒有問題，那么直接執行 maker 和 taker 的資產交割。
二、Wrapper 合約
在上述的 AirSwap 合約中，用戶通過 swap() 函數執行資產互換，這一流程非常清晰，沒有問題。但是這一合約存在一點不完美的地方，用戶只能通過 Token 進行資產互換，無法直接用 ETH 平臺幣參與其中。用戶可以先把 ETH 轉換成 WETH, 再用 WETH 參與互換，但無論如何，用戶使用體驗上多了一步。
為了降低用戶使用體驗上的摩擦，AirSwap 團隊與 2019 年 09 月 12 日 推出了 Wrapper 合約，其使用是自動將用戶轉入的 ETH 轉換成 WETH 之后再參與資產互換的過程，其關鍵流程如下：
1. 驗證 swap() 發起方與 taker 是相同的;
2. 如果用戶發起 swap() 有攜帶了 ETH 資產，并且需要轉換的 token 為 WETH, 那么就自動將 ETH 轉換成 WETH;
3. 直接調用 AirSwap 合約的 swap() 操作。
考慮到一種特殊的場景，Alice 希望通過 Wrapper 合約執行 AirSwap 資產互換，這一過程需要先由 Alice 自行在 AirSwap 合約中授權 Wrapper 合約，以允許 Wrapper 合約可以執行各自的資產交割流程。
由于區塊鏈的透明性，Eve 看到了 Alice 的授權操作，那么他就可以向 Wrapper 合約發起一筆惡意的訂單，其包含的內容如下：
1. order 中的有效時間、nonce 為一個非常大的數值;
2. order 中的 maker 對應的賬號為 Alice 的賬號;
3. order 中的 taker 為空;
4. order 的 signature 為空。
將上述構造好的 order 代入 AirSwap 的 swap() 函數，其中 1，2 兩步的驗證由于是 taker 控制的，不會有問題，我們重點看下第三步驗證 maker 信息：
由于此時 AirSwap 合約是由 Wrapper 合約調用的，那么 msg.sender 即 Wrapper 合約的地址，前文講到，Wrapper 合約是經過 Alice 授權可直接控制 Alice 的資產，此時雖然 Eve 沒有權限操作 Alice 的資產，但此時可以通過 Wrapper 控制，也就間接地控制了 Alice 的資產。
安全規避
PeckShield 安全人員分析發現，截止至 2019 年 09 月 28 日為止，共有 6 個賬號執行了revoke()操作，以解除對Wrapper合約的授權，還有 12 個賬號存在安全風險，這剩下的所有賬號應當立即執行revoke()操作，或者將賬號中的資產轉移至未對Wrapper授權過的安全賬號。
任何的代碼在上線生產環境之前都應當得到充分的測試和驗證，特別是承載著用戶價值的 DEX 平臺。在產品增加新特性之時，一定要考慮到舊特性的兼容性與安全，新特性的引入不應該觸發舊產品中設計不完備的地方。
附錄
