兩天內遭遇兩次攻擊 DeFi 協議 FEG 真的傷不起

前言

北京時間 2022 年 5 月 16 日，知道創宇區塊鏈安全實驗室 監測到多鏈 DeFi 協議 FEG 遭到閃電貸攻擊，攻擊者竊取 144 ETH 和 3280 BNB，損失約 130 萬美元。

5 月 17 日，多鏈 DeFi 協議 FEG 再次受到攻擊，攻擊者竊取 291 ETH 和 4343 BNB，損失約 190 萬美元，其中 BSC 130 萬美元，以太坊鏈 60 萬美元。

分析

該協議在 BSC 和 Ether 上都被攻擊了，下面的圖分別是兩鏈上的攻擊事件交易哈希。本次攻擊事件主要原因是 swapToSwap() 函數中 path 地址可被攻擊者控制。

基礎信息

攻擊合約：0x9a843bb125a3c03f496cb44653741f2cef82f445

攻擊者地址：0x73b359d5da488eb2e97990619976f2f004e9ff7c

漏洞合約地址：

BSC: 0x818e2013dd7d9bf4547aaabf6b617c1262578bc7

Ether: 0xf2bda964ec2d2fcb1610c886ed4831bf58f64948

攻擊 tx：

BSC:0x77cf448ceaf8f66e06d1537ef83218725670d3a509583ea0d161533fda56c063

Ether:0x1e769a59a5a9dabec0cb7f21a3e346f55ae1972bb18ae5eeacdaa0bc3424abd2

攻擊流程

1.攻擊者 0x73b3 調用事先創建好的攻擊合約 0x9a84 從 DVM 中閃電貸借出 915.842 WBNB，接着將其中的 116.81 WBNB 兌換成 115.65 fBNB。

2.攻擊者 0x73b3 通過攻擊合約 0x9a84 創建了 10 個合約以便後面利用漏洞。

3.攻擊者 0x73b3 將第一步中兌換得到的 fBNB 通過函數 depositInternal() 抵押到 FEGexPRO 合約 0x818e 中。

4.攻擊者 0x73b3 調用 depositInternal() 和 swapToSwap() 函數使得 FEGexPRO 合約 0x818e 授權 fBNB 給第二步創建好的合約，重復多次調用授權 fBNB 給創建的 10 個合約。

5、由於上一步中已經將攻擊者 0x73b3 創建的 10 個合約都已授權，攻擊者用這些已被授權的合約調用 transferFrom() 函數將 FEGexPRO 合約 0x818e 每次轉走 113.452 fBNB。

6、攻擊者 0x73b3 又從 PancakePair 的 LP 交易對 0x2aa7 中借出 31217683882286.007 的 FEG 和 423 WBNB 並重復上面的 第三步、第四步和第五步，最終獲得 。

7、最後歸還閃電貸，將上面攻擊獲得的所有 WBNB 轉入攻擊合約 0x9a84 中。

細節

查看 FEGexPRO 合約，我們能看到 depositInternal() 函數和 swapToSwap() 函數的具體邏輯。其中 depositInternal() 函數進行質押，用戶的余額受到合約當前代幣余額的影響，第一次攻擊者正常質押後 balance 也正常增加，而由於當前合約代幣余額沒變，後面的質押只需要傳入最小值調用即可。

通過調用 swapToSwap() 函數傳入惡意的 path 地址參數，當前合約代幣余額並不會受到影響，IERC20(address(Main)).approve(address(path), amt); 這樣就能給 path 地址進行當前合約 fBNB 的授權。

攻擊者通過反復調用 depositInternal() 和 swapToSwap()就可以讓 FEGexPRO 合約將 fBNB 反復授權給攻擊者傳入的惡意合約 path 地址。其他地址轉走的代幣數量就是攻擊者第一次質押的代幣數量減去手續費的數量。通過查看 Debugger 中的信息，我們可以發現傳入的 path 地址參數都是攻擊流程中創建的合約地址。

後續

在 16 日的攻擊之後，次日攻擊者又進行了一次攻擊，但更換了攻擊地址。

攻擊合約：0xf02b075f514c34df0c3d5cb7ebadf50d74a6fb17

攻擊者地址：0xf99e5f80486426e7d3e3921269ffee9c2da258e2

漏洞合約：0xa3d522c151ad654b36bdfe7a69d0c405193a22f9

攻擊 tx：

BSC:0xe956da324e16cb84acec1a43445fc2adbcdeb0e5635af6e40234179857858f82

Ether:0c0031514e222bf2f9f1a57a4af652494f08ec6e401b6ae5b4761d3b41e266a59

由於 R0X 漏洞合約 0xa3d5 未开源，我們試着從 Debugger 中進行分析，發現和第一次的攻擊流程類似，但還用了 BUY() 輔助存入和 SELL() 函數進行輔助提取。

總結

該次攻擊的主要原因是未驗證 swapToSwap() 函數中 path 地址參數，導致可以被攻擊者任意傳入使得 FEGexPRO 合約將自身代幣授權給攻擊者傳入的所有惡意 path 地址。建議合約在开發時要對所有傳入的參數進行校驗，不要相信攻擊者傳入的任何參數。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。