Furucombo 此次事故並不在安全漏洞的範疇內，主要的原因在於官方將未啟用的 AaveV2 Proxy 合約新增進了自己的白名單中，並且未對 AaveV2 Proxy 合約進行初始化，導致攻擊者有機可乘。與 Furucombo 互動過的使用者應及時撤銷相關授權，避免進一步損失。

據鏈聞訊息，著名 DeFi 專案 Furucombo 被黑，損失約 1500 萬美元。慢霧安全團隊第一時間介入分析，並將攻擊細節分享給大家。

攻擊細節分析

但是如果事情那麼簡單，那麼本次分析不值一提。問題遠比想象的複雜得多。

如上圖所示攻擊者的入口在 Furucombo 的 batchExec 函式，我們先對 batchExec 函式進行分析：

以上是 Furucombo Proxy 合約的 batchExec 函式的具體實現，其中 _preProcess 和 _postProcess 合約分別是對呼叫前後做一些資料上的處理，不涉及具體的呼叫邏輯，這邊可以先忽略。我們主要觀察核心的 _execs 函式：

透過對 execs 程式碼的分析不難發現，函式的主要邏輯是對 configs 陣列的資料做檢查，並根據 configs 陣列的資料對 data 進行一些處理。但是回顧上文中攻擊者的呼叫資料，不難發現攻擊者的呼叫資料中，configs 的資料是一個 0 地址：

這裡有一個 trick，由於 0 地址是一個 EOA 地址，所有對 EOA 地址的函式呼叫都會成功，但是不會返回任何結果。結合這個 trick，execs 函式中的關於 configs 資料的部分可以先暫時忽略。直接看到最後的核心 _exec 函式：

最後一步，便是呼叫 _to 地址，也就是官方指定的 AaveV2 Proxy 合約的 initialize 函式，將攻擊者自己的惡意地址設定成 AaveV2 Proxy 合約的邏輯地址。透過對 Furucombo 合約的分析，可以發現整個呼叫流程上沒有出現嚴重的安全點，對呼叫的地址也進行了白名單的檢查。那麼問題只能是出在了對應要呼叫的代理邏輯上，也就是 AaveV2 Proxy 合約。

我們直接分析 AaveV2 Proxy 合約的 initialize 函式的邏輯：

可以看到 initialize 函式是一個 public 函式，並在開頭就檢查了 _implementation 是否是 0 地址，如果是 0 地址，則丟擲錯誤。這個檢查的目的其實就是檢查了 _implementation 是否被設定了，如果被設定了，就無法再次設定。根據這個設定，不難想出 initialize 這個函式只能呼叫一次。除非 AaveV2 Proxy 從來沒有設定過 _implementation，否則這個呼叫是不會成功的。難道 Furucombo 真的沒有設定過對應的 _implementation 嗎？帶著這樣的疑問，我們檢查了交易內的狀態變化。如下：

可以看到，交易中改變了儲存位置為 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc 的內容，而寫入的內容正是攻擊者自己的惡意合約地址 0x86765dde9304bea32f65330d266155c4fa0c4f04。

而0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc 這個位置，正是 _implementation 資料的儲存地址。

也就是說，官方從來沒有設定過 AaveV2 Proxy 合約的 _implementation 地址，導致攻擊者鑽了這個空子，造成了 Furucombo 資產損失。

總結

透過對整個事件的分析來看，Furucombo 此次事故並不在安全漏洞的範疇內，主要的原因在於官方將未啟用的 AaveV2 Proxy 合約新增進了自己的白名單中，並且未對 AaveV2 Proxy 合約進行初始化，導致攻擊者有機可乘。

建議

目前，由於 Furucombo 遭受攻擊，導致任何將代幣授權過給 Furucombo 合約 (0x17e8ca1b4798b97602895f63206afcd1fc90ca5f) 的使用者都將面臨資金損失的風險。

慢霧安全團隊建議與 Furucombo 互動過的使用者檢查是否有將相關代幣授權給 Furucombo 合約。如有授權，應及時撤銷相關授權，避免進一步損失。

資訊內容不夠成投資建議，投資者應獨立決策自行承擔風險。