原標題： Exploiting Primitive Finance Approval Flaws
來源： Amber Group區塊鏈安全專家吳家志博士
事件摘要
2月24日，一篇關於Primitive Finance （以太坊鏈上衍生品協議）的漏洞分析報告在圈內引發關注， 報告描述了三個白帽攻擊（以安全漏洞排查為目的的黑客攻擊）以及漏洞原理。一個多月後的4月14日，以Amber Group區塊鏈安全專家吳家志博士為代表的團隊，發現了一個錢包地址有超過100萬美金的資產（ 500 WETH ）存在風險。在本地複現攻擊後，其團隊通過Immunefi （ DeFi漏洞懸賞平台）聯繫了Primitive項目方，並成功協助潛在的受害者重置了WETH授權，解除危機。這篇文章將介紹該團隊如何在模擬環境中利用此漏洞，以及如何通過區塊鏈數據分析找到潛在的受害者錢包地址。
原理：智能合約中的裂隙
在目前EVM （以太坊虛擬機）及ERC-20 （以太坊智能合約的一種協議標準）的架構中，當用戶與智能合約交互時，智能合約本身缺少一個能從代碼層面捕捉到ERC-20轉賬事件的回調機制。例如當Alice給Bob發100個XYZ代幣時， Bob的XYZ餘額會被更新在XYZ合約裡。但是Bob如何知道他的XYZ變多了呢？他可以查Etherscan （以太坊瀏覽器）或者其錢包App自動從以太坊節點取得的最新余額。如果Alice將100 XYZ發給一個智能合約Charlie ， Charlie如何得知他的XYZ餘額增加了呢？
事實上Charlie沒辦法在收到100 XYZ的當下主動取得他最新的餘額，原因是這個轉賬是在XYZ合約上發生的，不在Charlie合約。智能合約部署完成後就像操作系統一樣，是一堆代碼放在某個地方，需要被調用了才會發生作用。為了解決這個難題，在ERC-20標準有一個被廣泛使用的機制— approve()/transferFrom() 。
舉例來說，當Alice需要往Charlie存入100個XYZ代幣時， Alice可以事先授權Charlie使用她的100 XYZ額度，此時Charlie的deposit()函數就可以在一個交易里通過transferFrom()主動將Alice錢包裡的100 XYZ取出，並且更新Charlie合約的狀態（例如增加Alice的XYZ存款餘額cXYZ ）。為了減少摩擦，很多DApp甚至會讓用戶授權無限多的XYZ額度給項目方地址，這樣可以讓後續的transferFrom()調用直接成功，免除掉多次授權的點擊以及手續費，這等同於將Charlie加白。這個方案留下了一個隱患，萬一Charlie作惡或是被攻擊了， Alice的資產就會有危險。
這個發生於2020年6月18日的意外證實了一個被控製或存在問題的智能合約可以如何被利用並且造成資產損失，如下代碼所示， safeTransferFrom ()雖然名為safe 的transferFrom卻意外被宣告成公開函數，導致任何人都可以使用Bancor合約的身份轉移任意用戶（ _from ）任意數量（ _value ）的任意資產（ _token ）到任意的地址（ _to ）。
簡單舉例來說，如果Alice正好使用過Bancor並且授權Bancor無限額度使用她的DAI ，則一旦她的錢包裡DAI餘額大於零時，黑客就可以立即把她的DAI轉走。
診斷：黑客是怎樣繞開“安檢”的？
根據上文的漏洞分析報告所述，這個外部函數有一個類似的漏洞，但無法像Bancor的漏洞一樣被直接利用。事實上，攻擊者需要偽造兩個ERC20代幣合約，一個Uniswap資金池，並且發起一筆Uniswap閃電貸繞過下圖標註的msg.sender == address(this)檢查。聽起來複雜，但對於有經驗的黑客來說，這並不是太困難。
Primitive為何需要實現flashMintShortOptionsThenSwap()這樣一個接口呢？其實是有特定使用場景的，在openFlashLong ()函數可以看到， flashMintShortOptionsThenSwap()會被封裝在一個Uniswap的flash-swap調用參數里，在第1371行觸發flash-swap之後，由回調函數UniswapV2Call()調起。此時由於UniswapV2Call()在Primitive合約裡，便可以通過上述msg.sender == address(this)檢查。
值得注意的是，在openFlashLong ()函數里，第1360行寫的是msg.sender ，表示在正常的情況下， Primitive只能使用調用者本身的資金，然而攻擊者可以通過偽造的pair以及params用類似於1371行的方式直接調用Primitive合約的UniswapV2Call()並繞過flashMintShortOptionsThenSwap()的檢查。由於params在這情況下可以完全被控制， 1360行的msg.sender便可以被替換成任意曾經授權Primitive的錢包地址，然後通過flashMintShortOptionsThenSwap()裡的transferFrom()調用盜取資產。
追踪：找出可能的受害者
如果一個黑客碰巧知道某位“大戶”曾授權有問題的合約，他可以輕易利用這個漏洞盜取受害人大量的資金。然而，這件事情如果僅使用區塊瀏覽器是很難做到的，尤其在合約已經部署了較長時間，並有大量用戶量的情況下。其中需要分析的數據並非是靠人工搜索Etherscan能夠實現的。
Google Cloud Public Datasets （由Google託管在BigQuery的數據集）在此時可發揮作用。由於每一個成功的approve()調用都會在以太坊上發出一個Approval()事件，我們可以通過BigQuery （ Google的雲數據倉庫解決方案，用於處理“大數據”報告）服務找出所有事件並且通過一些方法過濾出我們感興趣的部分，例如_spender是Primitive合約的所有事件。
下面是我們在GCP上實際用來找出潛在受害者使用的SQL語句，其中第五行可以看到我們限定搜索的以太坊數據庫及記錄事件的表，第七行過濾出Approval()事件，第八行過濾了特定的_spender 。此外，第六行將區塊高度範圍設定在Pirmitive合約部署之後，這可以大幅降低BigQuery掃過的數據量，這類的SQL優化會直接反應在你的GCP賬單裡。
接下來，我們可以進一步優化SQL查詢將已經通過approve(_spender, 0)重置授權的賬號從清單中刨除，得到最終的賬號列表。有了最終的列表，我們利用一個腳本監控著這些賬號，並且在這些危險賬號收到大量資產時發出預警，因為這很可能會造成嚴重的損失。
在一個星期三的清晨，機器人發出了預警，有一個可能的受害人在北京時間4月13日清晨5點24分收到了將近500 WETH的資產，價值超過一百萬美金。相較於已公開的三次白帽攻擊，這個受害人如果被成功攻擊，所損失的金額將高於稍早的三個案例的總和。
我們在北京時間9:32緊急聯繫了Primitive項目的漏洞賞金計劃運營方Immunefi並且向他們展示我們如何（重新）利用這個漏洞在模擬環境中盜取受害人的500 WETH ，並且提供包括下面的截屏等證據。
在Primitive團隊的幫助下，潛在的受害人於10:03將WETH授權重置，解除危機。
兩天后， Primitive團隊也針對此發現給予漏洞獎勵並發佈公開致謝。該筆賞金發稿前已捐助給CryptoRelief （一家致力於援助印度新冠疫情的救濟基金）。
復現：分步拆解漏洞的利用
漏洞利用的第一步，我們需要準備兩個ERC20合約： Redeem及Option 。
其中Redeem合約是一個標準的ERC20 ，我們只需要基於OpenZeppelin的實現將mint()接口暴露出來，方便我們控制代幣數量，如下所示：
Option合約會相對複雜一點，從下面的代碼片段可以看到，我們需要刻意構造一些全局變量（例如redeemToken ），以及公開函數（例如getBaseValue() ），這些都是在Primitive的業務邏輯會用到的。此外，我們還需要傳入三個參數來初始化Option合約：
·
redeemToken :稍早構造的Redeem合約地址
·
underlyingToken :攻擊目標賬號所持有的資產合約地址
·
beneficiary :受益人地址，也就是攻擊成功後將受害人資產轉移的目標地址
這裡需要特別說明的是mintOptions()這個函數，從上面的代碼可以看到，它會直接把所有的underlyingToken發給beneficiary地址。這是因為下面的內部函數mintOptionWithUnderlyingBalance()函數在被flashMintShortOptionsThenSwap ()時會將underlyingToken發給Option代幣合約，並且通過mintOptions()調用鑄造Option代幣。因此，我們在偽造的Option合約裡，可以直接把mintOptions()當作一個提幣調用，將underlyingToken發給beneficiary （也就是發起攻擊的地址），用於之後歸還閃電貸的資金。
接下來，我們可以用剛剛創建的Redeem及Option代幣創建一個Uniswap的流動性池子，這個池子的地址將用來接收從受害人錢包轉出的資金。事實上，每個Uniswap池子裡有等價的兩種資產，例如WETH及Redeem （也就是Option.redeemToken() ），為了完成漏洞利用，我們必須為池子注入流通性。 Redeem是我們自己創建的，可以鑄造無限量的代幣，但WETH呢？
在閃電貸的幫助下，我們基本上可以利用無限數量的資金來做如何事情，只要確保能在一個交易中歸還資金即可。在這個案例中，我們使用Aave V2的閃電貸借了相當於受害人總資產99.7%的資金存入上述的流動性池。
根據Aave的設計，需要實現一個回調函數executeOperation()執行獲得貸款資金後的操作（例如調用Lib.trigger() ），並且在最後通過approve()調用授權Aave合約取走閃電貸的資產以及手續費。
總結
在基於EVM的智能合約世界裡， approve()/transferFrom()是長久以來存在的固有問題。對於DeFi用戶而言，需要多留意你的錢包地址是否正允許著其他人使用你的資產，並且定期重置資產使用權。對於項目方而言，需要在上線之前花更多心思和時間從各種可能的角度測試，甚至攻擊你的代碼，因為你正在編程的，是每位用戶的真金白銀。
