攻擊細節分析
攻擊細節分析
攻擊細節分析
二級標題
攻擊細節分析
本次發生問題的合約在Furucombo 本身的代理合約當中。整個攻擊流程很簡單。攻擊者通過設置了Furucombo 的AaveV2 Proxy 的邏輯地址導致後續通過Furucombo 代理合約調用的邏輯全部轉發到攻擊者自己的惡意合約上，導致任意資金被盜。
但是如果事情那麼簡單，那麼本次分析不值一提。問題遠比想像的複雜得多。
如上圖所示攻擊者的入口在Furucombo 的batchExec 函數，我們先對batchExec 函數進行分析：
以上是Furucombo Proxy 合約的batchExec 函數的具體實現，其中_preProcess 和_postProcess 合約分別是對調用前後做一些數據上的處理，不涉及具體的調用邏輯，這邊可以先忽略。我們主要觀察核心的_execs 函數：
通過對execs 代碼的分析不難發現，函數的主要邏輯是對configs 數組的數據做檢查，並根據configs 數組的數據對data 進行一些處理。但是回顧上文中攻擊者的調用數據，不難發現攻擊者的調用數據中，configs 的數據是一個0 地址：
這裡有一個trick，由於0 地址是一個EOA 地址，所有對EOA 地址的函數調用都會成功，但是不會返回任何結果。結合這個trick，execs 函數中的關於configs 數據的部分可以先暫時忽略。直接看到最後的核心_exec 函數：
_exec 函數的邏輯也很簡單，在校驗了_to 地址後，直接就將data 轉發到指定的_to 地址上了。而通過對攻擊交易的分析，我們能發現這個_to 地址確實是官方指定的合法地址。
最後一步，便是調用_to 地址，也就是官方指定的AaveV2 Proxy 合約的initialize 函數，將攻擊者自己的惡意地址設置成AaveV2 Proxy 合約的邏輯地址。通過對Furucombo 合約的分析，可以發現整個調用流程上沒有出現嚴重的安全點，對調用的地址也進行了白名單的檢查。那麼問題只能是出在了對應要調用的代理邏輯上，也就是AaveV2 Proxy 合約。
二級標題
總結
總結
二級標題
總結
參考鏈接：
參考鏈接：
參考鏈接：
攻擊交易：
https://ethtx.info/mainnet/0x6a14869266a1dcf3f51b102f44b7af7d0a56f1766e5b1908ac80a6a23dbaf449
