ETH:慢霧：詳解 Uniswap 的 ERC777 重入風險

前言

4 月 18 日，Tokenlon 宣布暫停 imBTC 轉賬，因其發現有攻擊者通過 ERC777 在 Uniswap 流動性合約中的重入漏洞，對 ETH-imBTC 池循環套利。此次的攻擊手法是一個存在于 Uniswap v1 上的已知漏洞，該漏洞最早由 Consensys 于 2019 年 4 月發現，當時 Consensys 只是發現了該風險，還沒有發現可以利用這種手法進行攻擊的 token。隨后，在 imBTC 上線 Uniswap 后，由于 imBTC 是基于 ERC777 實現的，通過組合 ERC777 的特性及 Uniswap 代碼上的問題，使攻擊者可以通過重入漏洞實現套利。下面，我們將來分析此次套利中的攻擊手法和具體的細節。

知識準備

ERC777 協議是以太坊上的代幣標準協議，該協議是以太坊上 ERC20 協議的改進版，主要的改進點如下：

1. 使用和發送以太相同的理念發送 token，方法為：send(dest, value, data)

2. 合約和普通地址都可以通過注冊 tokensToSend hook 函數來控制和拒絕發送哪些token（拒絕發送通過在hook函數tokensToSend 里 revert 來實現）

慢霧：Apple Store惡意釣魚程序可模仿正常應用程序，盜取賬號密碼以繞過2FA:7月25日消息，慢霧首席信息安全官23pds發推提醒用戶注意Apple ID出現的最新攻擊案例，其中Apple Store出現惡意釣魚程序，通過模仿正常應用程序盜取用戶賬號和密碼，然后攻擊者把自己的號碼加入雙重認證的信任號碼，控制賬號權限，用來繞過蘋果的2FA。“加密貨幣用戶務必注意，因為目前有不少用戶、錢包的備份方案是iCloud備份，一旦被攻擊，可能造成資產損失”。[2023/7/25 15:56:56]

3. 合約和普通地址都可以通過注冊 tokensReceived hook 函數來控制和拒絕接受哪些token（拒絕接受通過在hook函數tokensReceived 里 revert 來實現）

4. tokensReceived 可以通過 hook 函數可以做到在一個交易里完成發送代幣和通知合約接受代幣，而不像 ERC20 必須通過兩次調用（approve/transferFrom）來完成

5. 持有者可以"授權"和"撤銷"操作員（operators: 可以代表持有者發送代幣） 這些操作員通常是（去中心化）交易所、支票處理機或自動支付系統

慢霧：Transit Swap事件中轉移到Tornado Cash的資金超過600萬美元:金色財經報道，慢霧 MistTrack 對 Transit Swap 事件資金轉移進行跟進分析，以下將分析結論同步社區：

Hacker#1 攻擊黑客（盜取最大資金黑客），獲利金額：約 2410 萬美元

1: 0x75F2...FFD46

2: 0xfa71...90fb

已歸還超 1890 萬美元的被盜資金；12,500 BNB 存款到 Tornado Cash；約 1400 萬 MOONEY 代幣和 67,709 DAI 代幣轉入 ShibaSwap: BONE Token 合約地址。

Hacker#2 套利機器人-1，獲利金額：1,166,882.07 BUSD

0xcfb0...7ac7(BSC)

保留在獲利地址中，未進一步轉移。

Hacker#3 攻擊模仿者-1，獲利金額：356,690.71 USDT

0x87be...3c4c(BSC)

Hacker#4 套利機器人-2，獲利金額：246,757.31 USDT

0x0000...4922(BSC)

已全部追回。

Hacker#5 套利機器人-3，獲利金額：584,801.17 USDC

0xcc3d...ae7d(BSC)

USDC 全部轉移至新地址 0x8960...8525，后無進一步轉移。

Hacker#6 攻擊模仿者-2，獲利金額：2,348,967.9 USDT

0x6e60...c5ea(BSC)

Hacker#7 套利機器人-4，獲利金額：5,974.52 UNI、1,667.36 MANA

0x6C6B...364e(ETH)

通過 Uniswap 兌換為 30.17 ETH，其中 0.71 支付給 Flashbots，剩余 ETH 未進一步轉移。[2022/10/6 18:41:10]

6. 每個代幣交易都包含 data 和 operatorData 字段， 可以分別傳遞來自持有者和操作員的數據

慢霧：Equalizer Finance被黑主要在于FlashLoanProvider合約與Vault合約不兼容:據慢霧區消息，6 月 7 日，Equalizer Finance 遭受閃電貸攻擊。慢霧安全團隊以簡訊形式將攻擊原理分享如下：

1. Equalizer Finance 存在 FlashLoanProvider 與 Vault 合約，FlashLoanProvider 合約提供閃電貸服務，用戶通過調用 flashLoan 函數即可通過 FlashLoanProvider 合約從 Vault 合約中借取資金，Vault 合約的資金來源于用戶提供的流動性。

2. 用戶可以通過 Vault 合約的 provideLiquidity/removeLiquidity 函數進行流動性提供/移除，流動性提供獲得的憑證與流動性移除獲得的資金都受 Vault 合約中的流動性余額與流動性憑證總供應量的比值影響。

3. 以 WBNB Vault 為例攻擊者首先從 PancekeSwap 閃電貸借出 WBNB

4. 通過 FlashLoanProvider 合約進行二次 WBNB 閃電貸操作，FlashLoanProvider 會先將 WBNB Vault 合約中 WBNB 流動性轉給攻擊者，隨后進行閃電貸回調。

5. 攻擊者在二次閃電貸回調中，向 WBNB Vault 提供流動性，由于此時 WBNB Vault 中的流動性已經借出一部分給攻擊者，因此流動性余額少于預期，則攻擊者所能獲取的流動性憑證將多于預期。

6. 攻擊者先歸還二次閃電貸，然后從 WBNB Vault 中移除流動性，此時由于 WBNB Vault 中的流動性已恢復正常，因此攻擊者使用添加流動性獲得憑證所取出的流動性數量將多于預期。

7. 攻擊者通過以上方式攻擊了在各個鏈上的 Vault 合約，耗盡了 Equalizer Finance 的流動性。

此次攻擊的主要原因在于 Equalizer Finance 協議的 FlashLoanProvider 合約與 Vault 合約不兼容。慢霧安全團隊建議協議在進行實際實現時應充分考慮各個模塊間的兼容性。[2022/6/8 4:09:22]

7. 可以通過部署實現 tokensReceived 的代理合約來兼容沒有實現tokensReceived 函數的地址

慢霧：PAID Network攻擊者直接調用mint函數鑄幣:慢霧科技發文對于PAID Network遭攻擊事件進行分析。文章中指出，在對未開源合約進行在反編譯后發現合約的 mint 函數是存在鑒權的，而這個地址，正是攻擊者地址(0x187...65be)。由于合約未開源，無法查看更具體的邏輯，只能基于現有的情況分析。慢霧科技分析可能是地址(0x187...65be)私鑰被盜，或者是其他原因，導致攻擊者直接調用 mint 函數進行任意鑄幣。

此前報道，PAID Network今天0點左右遭到攻擊，增發將近6000萬枚PAID代幣，按照當時的價格約為1.6億美元，黑客從中獲利2000ETH。[2021/3/6 18:21:08]

在這里，我們需要特別關注的點是第二點，即 ERC777 標準中的 tokenToSend 函數，根據 ERC777 協議的定義，遵循該標準的 token 代幣在每一次發生代幣轉賬的時候都會去嘗試調用代幣發送者 tokensToSend 函數，而代幣持有者可以通過在 ERC1820 注冊合約注冊自己的合約并通過在這個 hook 函數中定義一些操作來處理代幣轉賬的過程中的某些流程，如拒絕代幣發送或其他操作。

了解這些關鍵點，有助于我們理解這次攻擊的具體攻擊手法。現在開始，我們可以稍微加速，看看對于 Uniswap 而言，這次到底發生了什么？

慢霧：Let's Encrypt軟件Bug導致3月4日吊銷 300 萬個證書:Let's Encrypt由于在后端代碼中出現了一個錯誤，Let's Encrypt項目將在撤銷超過300萬個TLS證書。詳情是該錯誤影響了Boulder，Let's Encrypt項目使用該服務器軟件在發行TLS證書之前驗證用戶及其域。慢霧安全團隊提醒：數字貨幣行業有不少站點或內部系統為安全目的而使用 Let's Encrypt 自簽證書，請及時確認是否受到影響。如有影響請及時更新證書，以免造成不可預知的風險。用戶可查看原文鏈接在線驗證證書是否受到影響。[2020/3/4]

細節分析

通過 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 的代碼。

上面是代碼是 Uniswap 的 ethToTokenSwapInput 函數的代碼，根據代碼分析， Uniswap 的 ethToTokenSwapInput 函數會調用 ethToTokenInput 函數，然后會先通過 getInputPrice 獲取代幣能換取的 eth 數量，之后通過 send 函數將 eth 發給用戶，最后再通過 transferFrom 把代幣轉進合約。我們繼續跟進 getInputPrice 函數。

通過分析 getInputPrice 函數，我們能知道，ETH 獲取量計算的公式為

把該公式放到 ethToTokenInput 函數的上下文中，該公式就變成了

在該公式下，一次正常的 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 做事商的損失。

防御方法

1. 在 Uniswap 的 tokenToEthSwapInput 函數中加入 OpenZeppelin 的 ReentrancyGuard 函數，防止重入問題。

2. 在進行代幣交換的時候，先扣除用戶的代幣，再將 ETH 發送給用戶。

同時，針對本次攻擊事件慢霧安全團隊建議：

1. 在關鍵的業務操作方法中加入鎖機制，如：OpenZeppelin 的 ReentrancyGuard

2. 開發合約的時候采用先更改本合約的變量，再進行外部調用的編寫風格

3. 項目上線前請優秀的第三方安全團隊進行全面的安全審計，盡可能的發現潛在的安全問題

4. 多個合約進行對接的時候也需要對多方合約進行代碼安全和業務安全的把關，全面考慮各種業務場景相結合下的安全問題

5. 合約盡可能的設置暫停開關，在出現“黑天鵝”事件的時候能夠及時發現并止損

6. 安全是動態的，各個項目方也需要及時捕獲可能與自身項目相關的威脅情報，及時排查潛在的安全風險

最后的思考

這兩天的 DeFi 世界被鬧得沸沸揚揚，imBTC 作為 ERC777 代幣首當其沖，ERC777 協議也飽受詬病，但是看完分析，造成此次的攻擊事件原因，真的是 imBTC 或者是 ERC777 協議的問題嗎？

如果 Uniswap 做好了 ERC777 的兼容，使用 ReentrancyGuard，并在代幣交換的時候先扣除用戶的代幣，再將 ETH 發送給用戶，這樣的問題是不是就不會發生？

imBTC 作為 以太坊上 token 化的比特幣代幣協議，其安全性在自身單獨運行的時候并不存在問題，第三方 DeFi 平臺在接入的時候，應需要充分考慮平臺本身的業務邏輯與接入代幣之間的兼容性，才能避免因兼容性發生不必要的安全問題。而不是簡單的將問題歸咎于協議和代幣提供方。

Tags：ETHSWAPTOKENKENLETH價格MatrixswapDxChain TokenLive NFT Token

Gate.io