前言
北京時間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 地址。建議合約在開發時要對所有傳入的參數進行校驗，不要相信攻擊者傳入的任何參數。
