DeFi浪潮下的“狠角色”DEX夠安全嗎？

如今，隨著人們對DeFi 的興趣日益濃厚，DEX（即去中心化交易所）風靡一時。它們解決了常見的CEX （即中心化交易所）問題，那我們也會問，DEX夠安全嗎？

在上一篇說明了代幣本身的安全問題後（ 純乾貨分享（一） | DEFI安全問題之基礎篇），現在來聊聊DEX在兌換代幣時可能產生的安全問題。目前DEX主要面臨的安全問題大致可分成兩類：

（1）DEX項目本身存在的安全問題。

（2）作為第三方協議，與其他DEFI項目交互時產生的安全問題。

本文將對第一類安全問題進行介紹。

Part.1

-Decentralized Exchange

重入漏洞

重入漏洞在上一篇我們也提到過，它屬於需要防範的經典漏洞。與普通代幣的重入相比，Uniswap的重入漏洞的主要表現形式為：攻擊者在一筆兌換交易中利用Uniswap未及時更新價格前發起二次兌換，由於此時Uniswap未更新價格，使得二次兌換可兌出的代幣數量比正常兌換的多。此外，在Uniswap的重入攻擊中，攻擊者利用單筆交易可能只能獲得微小的收益，因此攻擊者往往傾向於使用閃電貸或者循環套利擴大戰果。

以imBTC攻擊事件為例，該事件是由於Uniswap V1在調用ERC777系列代幣時，未充分考慮合約回調的情況。

具體表現為：攻擊者使用imBTC代幣兌換ETH時（如圖1），合約先通過self.getInputPrice函數計算正確的ETH數額並將ETH發送到目標地址，然後調用self.token.transferFrom函數時，會調用imBTC合約的_callTokensToSend函數（如圖2），而_callTokensToSend函數會調用用戶指定存儲imBTC代幣的合約。因此，如果攻擊者部署存儲合約，並改寫其中TokensToSend函數，那麼當兌換代幣時，pair(兩種代幣組成的交易對)合約調用攻擊者部署的存儲合約，就可以回調pair進行二次兌換，而二次兌換時pair合約賬本還未更新，使得計算的ETH數額比正常兌換要多，以此來獲利。

詳細攻擊流程如下：

那麼，為什麼在第二次調用tokenToEthSwapInput函數兌換代幣時，發送的ETH會比正常兌換要多呢?我們可以用公式來還原可兌換代幣數量的代碼邏輯：

首先，正常兌換下，getInputPrice函數計算可兌換的ETH數量為:

且正常第二次可兌換的ETH數量為：

但重入後第二次可兌換的ETH數量為：

由此可知，在重入後第二次兌換中只有ETH的儲備量減少，而imBTC儲備量未增加。這樣在分母不增加的情況下，導致了等量的imBTC可以兌換更多的ETH。

針對此類安全問題，成都鏈安建議：

當合約涉及到資產轉移時，使用“檢查-生效-交互”模式來處理邏輯，對關鍵的業務操作可以使用OpenZeppelin官方的ReentrancyGuard進行修飾。

Part.2

-Decentralized Exchange

swap函數未對K值進行校驗

Uniswap的核心是常量乘積模型K=x*y，其中的K值是該pair合約持有代幣數量的乘積，且要求之後的每一筆交易完成後K值必須增加(考慮手續費)。因此如果不進行K值校驗，將很容易成為攻擊點。

以Impossible Finance事件為例，該項目是Uniswap的仿盤，實現了兩種兌換代幣的函數： cheapSwap和swap 。其中cheapSwap函數少了k值校驗（如圖6），但是項目方知道缺少K值校驗的後果，專門為cheapSwap函數增加了onlyIFRouter做修飾，來限制cheapSwap函數只能被指定的Router合約調用。

正常情況下，當用戶使用Router合約兌換代幣時，首先會使用getAmountsOut函數來計算正確的代幣數量amounts；然後調用safeTransferFrom將用戶的兌換消耗代幣轉入目標pair合約；最後，通過內部調用_ swap函數來執行cheapSwap函數將兌換代幣轉至目標地址。

但是，由於cheapSwap函數缺少了K值檢驗，如果攻擊者部署惡意代幣合約，在Router合約調用safeTransferFrom函數時，回調正常的pair合約進行同種兌換，由於，回調後的兌換使用的amounts仍是未更新之前的數據，已不符合改變賬本狀態之後的校驗，那麼攻擊會導致以錯誤的價格兌換出目標代幣，以此獲利。

該事件的具體攻擊步驟如下：

1. 在準備階段攻擊者部署了AAA代幣合約，並使用閃電貸借來1000WBNB，兌換65140個項目方的IF代幣。

2. 使用其中一半的IF代幣(32570個)與攻擊者自己部署的AAA代幣構建IF-AAA交易池。

3. 執行AAA-IF-BUSD路徑的代幣兌換，且當Router合約調用AAA代幣合約的transferFrom函數時會執行攻擊者的惡意代碼，重入至IF-BUSD的pair合約，並將另一半IF代幣正常兌換出221897個BUSD。

4. 回歸到AAA-IF-BUSD路徑的兌換，將之前計算的amounts值傳入_Swap函數中執行這筆兌換，用一半的IF又兌換了2521897個BUSBD。

5. 歸還閃電貸，完成攻擊。

針對此類安全問題，成都鏈安建議：

在關鍵的兌換函數中必須做k值校驗，不要為了節省gas和代碼量就將K值校驗和安全驗證依賴外部驗證，做到自身功能完善。

Part.3

-Decentralized Exchange

通縮代幣未設置pair為分紅例外

通縮代幣在交易時會產生額外的分紅與手續費。如果交易合約中包含了此類代幣，且沒有進行特殊處理，那麼，就可能導致交易對合約記錄的代幣儲量與實際的代幣可用餘額不一致。

以XSquid事件為例，XSquid是一種通縮代幣，未將其與WHT代幣組成的pair合約地址添加獎勵例外列表，造成了pair合約除了正常代幣兌換和流動性存儲外，還存有多餘的XSquid分紅獎勵代幣。因此，攻擊者就可以調用Swap函數將pair合約多餘的XSquid代幣轉換為WHT提取（如圖11），或者通過skim函數將多餘的XSquid代幣直接提取（如圖12）。

針對此類安全問題，成都鏈安建議：

DEX在添加通縮分紅型代幣時多注意手續費以及分紅的處理情況。在創建通縮分紅型代幣交易對時，可以添加獎勵例外來避免此類代幣的分紅問題。

此外，以下兩類不屬於DEX本身的安全問題，但是被項目方借助了DEX的特性實施詐騙，所以將其寫在文章末尾。

PART.1

詐騙交易池

這類問題主要是指項目方在自己發行的代幣裡留有後門，創建與主流代幣的交易池，誘使投資者使用手裡存在價值的代幣買入項目方代幣，並且不斷拉盤對投資者進行投資欺騙。

以下面的TRTC項目方為例，項目方創建了ETH-TRTC的交易池。但是在TRTC的代幣合約對transferFrom函數做了相關限制，要求代幣的轉出方為owner(管理員)或者為Uniswap。因此對於投資者，僅可以通過Uniswap買入TRTC代幣，而不能賣出TRTC代幣。最後由項目方把投資者投入的ETH提走跑路，給投資者帶來了巨大的損失。

PART.2

項目方Rug Pull

Rug Pull是指項目方捲走投資者資金跑路的行為，目前已成為DeFi生態系統的最大騙局類型，項目方刻意製造代幣價格暴漲的假象、許諾為提供流動性的投資者提供高回報等方式來大量聚集資金，一旦時機成熟就移除池子裡的流動性或將代幣捲走。這樣的例子在DeFi屢見不鮮，AnubisDAO、Meerkat Finance、TurtleDEX、Squid token魷魚幣等都是在捲款跑路之後，註銷網站和社交媒體銷聲匿跡，導致投資者承擔了巨大的損失。

寫在最後

成都鏈安建議項目方使用鎖倉和多重簽名來控制代幣流動性，避免出現砸盤跑路的情況。投資者不要被天上掉餡餅的事情沖昏頭腦，防範虛假宣傳。