編者按：本文來自正文二級標題
前言
二級標題
前言
前言
二級標題
據鏈聞消息，4 月18 日，Tokenlon 宣布暫停imBTC 轉賬，因其發現有攻擊者通過ERC777 在Uniswap 流動性合約中的重入漏洞，對ETH-imBTC 池循環套利。此次的攻擊手法是一個存在於Uniswap v1 上的已知漏洞，該漏洞最早由Consensys 於2019 年4 月發現，當時Consensys 只是發現了該風險，還沒有發現可以利用這種手法進行攻擊的token。隨後，在imBTC 上線Uniswap 後，由於imBTC 是基於ERC777 實現的，通過組合ERC777 的特性及Uniswap 代碼上的問題，使攻擊者可以通過重入漏洞實現套利。下面，我們將來分析此次套利中的攻擊手法和具體的細節。
二級標題
知識準備
ERC777 協議是以太坊上的代幣標準協議，該協議是以太坊上ERC20 協議的改進版，主要的改進點如下："4、tokensReceived 可以通過hook 函數可以做到在一個交易裡完成發送代幣和通知合約接受代幣，而不像ERC20 必須通過兩次調用（approve/transferFrom）來完成"和"5、持有者可以"5、持有者可以
和
授權
和
在這裡，我們需要特別關注的點是第二點，即ERC777 標準中的tokenToSend 函數，根據ERC777 協議的定義，遵循該標準的token 代幣在每一次發生代幣轉賬的時候都會去嘗試調用代幣發送者tokensToSend 函數，而代幣持有者可以通過在ERC1820 註冊合約註冊自己的合約並通過在這個hook 函數中定義一些操作來處理代幣轉賬的過程中的某些流程，如拒絕代幣發送或其他操作。
細節分析
了解這些關鍵點，有助於我們理解這次攻擊的具體攻擊手法。現在開始，我們可以稍微加速，看看對於Uniswap 而言，這次到底發生了什麼？
二級標題
細節分析
二級標題
細節分析
通過Etherscan 查詢攻擊者的其中一筆交易0x32c83905db61047834f29385ff8ce8cb6f3d24f97e24e6101d8301619efee96e
可以發現，攻擊者兩度向Uniswap 合約轉帳imBTC，金額同樣是0.00823084，然後從Uniswap 收取了兩筆ETH，看上去似乎是十分正常的兩筆交易，實際上卻是暗流湧動，另有玄機。為了更好的了解整一筆交易的細節，我們需要通過bloxy.info 來查看交易的具體細節。
通過查詢交易的細節，我們發現，攻擊者首先是通過ethToTokenSwapInput 函數向Uniswap 兌換了一些imBTC，然後再通過tokenToEthSwapInput 函數開始第一次用imBTC 換取ETH，然後Uniswap 先將ETH 轉給了攻擊者，再調用imBTC 的transferFrom 函數，由於imBTC 實現了ERC777 標準，所以在調用imBTC 的trasferFrom 函數的時候， imBTC 會對攻擊者的tokensToSend 函數進行調用。隨後，在攻擊者的tokensToSend 函數中，攻擊者會進行第二次用imBTC 換取ETH，然後流程結束。
從交易細節上看，這裡似乎還是沒有什麼問題，我們繼續跟踪UniSwap 的代碼。
通過分析getInputPrice 函數，我們能知道，ETH 獲取量計算的公式為
在該公式下，一次正常的imBTC 兌換ETH 的過程中，作為分母的imBTC 儲備量在兌換過後應該要上升，對應的ETH 儲備量會變小。
但是回顧攻擊者的操作方式，在攻擊者第一次發送imBTC 兌換ETH 的過程中，Uniswap 會先發送ETH 給攻擊者，這時候Uniswap 中ETH 儲備量減少，然後Uniswap 調用transferFrom 函數，(注意此時還未將攻擊者的imBTC 扣除)， 緊接著在transferFrom 函數中攻擊者調用的第二次的ethToTokenSwapInput 時，通過getInputPrice 獲取兌換的ETH 數量的公式會變成這樣：
二級標題
注意看，在第二次的兌換計算中，只有ETH 的儲備量變少了，而imBTC 的儲備量並未增加，這導致相比與單獨的調用ethToTokenSwapInput 函數，攻擊者可以通過重入的方式，在第二次使用imBTC 兌換ETH 的過程中，使計算公式的分子發生了變化，而公式的分母不會發生變化。相比正常的兌換，攻擊者通過重入方式進行的第二次兌換會獲取微小的利潤，導致有利可圖。重複這樣的過程，就能通過等量的imBTC 獲取更多的ETH，導致Uniswap 做事商的損失。
在關鍵的業務操作方法中加入鎖機制，如：OpenZeppelin 的ReentrancyGuard
開發合約的時候採用先更改本合約的變量，再進行外部調用的編寫風格
項目上線前請優秀的第三方安全團隊進行全面的安全審計，盡可能的發現潛在的安全問題
開發合約的時候採用先更改本合約的變量，再進行外部調用的編寫風格
項目上線前請優秀的第三方安全團隊進行全面的安全審計，盡可能的發現潛在的安全問題
多個合約進行對接的時候也需要對多方合約進行代碼安全和業務安全的把關，全面考慮各種業務場景相結合下的安全問題
安全是動態的，各個項目方也需要及時捕獲可能與自身項目相關的威脅情報，及時排查潛在的安全風險
合約盡可能的設置暫停開關，在出現“黑天鵝”事件的時候能夠及時發現並止損
二級標題
安全是動態的，各個項目方也需要及時捕獲可能與自身項目相關的威脅情報，及時排查潛在的安全風險
