慢霧：Furucombo被黑分析_COMB

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

本次發生問題的合約在Furucombo本身的代理合約當中。整個攻擊流程很簡單。攻擊者通過設置了Furucombo的AaveV2Proxy的邏輯地址導致后續通過Furucombo代理合約調用的邏輯全部轉發到攻擊者自己的惡意合約上，導致任意資金被盜。

慢霧：6月24日至28日Web3生態因安全問題損失近1.5億美元:7月3日消息，慢霧發推稱，自6月24日至6月28日，Web3生態因安全問題遭遇攻擊損失149,658,500美元，包括Shido、Ichioka Ventures、Blockchain for dog nose wrinkles、Chibi Finance、Biswap、Themis等。[2023/7/3 22:14:33]

但是如果事情那么簡單，那么本次分析不值一提。問題遠比想象的復雜得多。如上圖所示攻擊者的入口在Furucombo的batchExec函數，我們先對batchExec函數進行分析：

慢霧：利用者通過執行惡意提案控制了Tornado.Cash的治理:金色財經報道，SlowMist發布Tornado.Cash治理漏洞解析。 5月20日，Tornado.Cash遭受了治理攻擊，利用者通過執行惡意提案控制了Tornado.Cash的治理。5月13日，利用者發起了20提案，并在提案中說明20提案是對16提案的補充，具有相同的執行邏輯。但實際上，提案合約多了一個自毀邏輯，其創建者是通過create2創建的，具有自毀功能，所以在與提案合約自毀后，利用者仍可以部署不同的以與以前相同的方式將字節碼發送到相同的地址。不幸的是，社區沒有看到擬議合約中的犯規行為，許多用戶投票支持該提案。

在5月18日，利用者通過創建具有多個交易的新地址，反復將0代幣鎖定在治理中。利用提案合約可以銷毀并重新部署新邏輯的特性，利用者在5月20日7:18（UTC）銷毀了提案執行合約，并在同一地址部署了一個惡意合約，其邏輯是修改用戶在治理中鎖定的代幣數量。

攻擊者修改完提案合約后，于5月20日7:25（UTC）執行惡意提案合約。該提案的執行是通過 Delegatecall 執行的，因此，該提案的執行導致治理合約中由開發者控制的地址的代幣鎖定量被修改為 10,000。提案執行完成后，攻擊者從治理庫中解鎖了TORN代幣。金庫中的TORN代幣儲備已經耗盡，同時利用者控制了治理。[2023/5/21 15:17:00]

以上是FurucomboProxy合約的batchExec函數的具體實現，其中_preProcess和_postProcess合約分別是對調用前后做一些數據上的處理，不涉及具體的調用邏輯，這邊可以先忽略。我們主要觀察核心的_execs函數：

慢霧：去中心化期權協議Acutus的ACOWriter合約存在外部調用風險:據慢霧區消息，2022年3月29日，Acutus的ACOWriter合約遭受攻擊，其中_sellACOTokens函數中外部調用用到的_exchange和exchangeData參數均為外部可控，攻擊者可以通過此漏洞進行任意外部調用。目前攻擊者利用該手法已經盜取了部分授權過該合約的用戶的資產約72.6萬美金。慢霧安全團隊提醒使用過該合約的用戶請迅速取消對該合約的授權以規避資產被盜風險。[2022/3/29 14:25:07]

通過對execs代碼的分析不難發現，函數的主要邏輯是對configs數組的數據做檢查，并根據configs數組的數據對data進行一些處理。但是回顧上文中攻擊者的調用數據，不難發現攻擊者的調用數據中，configs的數據是一個0地址：

慢霧：Multichain(AnySwap)被黑由于anySwapOutUnderlyingWithPermit函數相關問題:據Multichain(AnySwap)早前消息，2022年01月18日，一個影響6個跨鏈Token的關鍵漏洞正在被利用。慢霧安全團隊進行分析后表示，此次主要是由于anySwapOutUnderlyingWithPermit函數為檢查用戶傳入的Token的合法性，且未考慮并非所有underlying代幣都有實現permit函數，導致用戶資產被未授權轉出。慢霧安全團隊建議：應對用戶傳入的參數是否符合預期進行檢查，且在與其他合約進行對接時應考慮好兼容性問題。[2022/1/19 8:57:49]

聲音 | 慢霧：Ghostscript存在多個漏洞:據慢霧區消息，Google Project Zero發布Ghostscript多個漏洞預警，遠端攻擊者可利用漏洞在目標系統執行任意代碼及繞過安全限制。Ghostscript 9.26及更早版本都受影響。軟件供應商已提供補丁程序。[2019/1/24]

這里有一個trick，由于0地址是一個EOA地址，所有對EOA地址的函數調用都會成功，但是不會返回任何結果。結合這個trick，execs函數中的關于configs數據的部分可以先暫時忽略。直接看到最后的核心_exec函數：

_exec函數的邏輯也很簡單，在校驗了_to地址后，直接就將data轉發到指定的_to地址上了。而通過對攻擊交易的分析，我們能發現這個_to地址確實是官方指定的合法地址。

最后一步，便是調用_to地址，也就是官方指定的AaveV2Proxy合約的initialize函數，將攻擊者自己的惡意地址設置成AaveV2Proxy合約的邏輯地址。通過對Furucombo合約的分析，可以發現整個調用流程上沒有出現嚴重的安全點，對調用的地址也進行了白名單的檢查。那么問題只能是出在了對應要調用的代理邏輯上，也就是AaveV2Proxy合約。我們直接分析AaveV2Proxy合約的initialize函數的邏輯：

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

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

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

通過對整個事件的分析來看，Furucombo此次事故并不在安全漏洞的范疇內，主要的原因在于官方將未啟用的AaveV2Proxy合約添加進了自己的白名單中，并且未對AaveV2Proxy合約進行初始化，導致攻擊者有機可乘。建議

目前，由于Furucombo遭受攻擊，導致任何將代幣授權過給Furucombo合約(0x17e8ca1b4798b97602895f63206afcd1fc90ca5f)的用戶都將面臨資金損失的風險。慢霧安全團隊建議與Furucombo交互過的用戶檢查是否有將相關代幣授權給Furucombo合約。如有授權，應及時撤銷相關授權，避免進一步損失。參考鏈接：代幣授權檢查地址：https://approved.zone/攻擊交易：https://ethtx.info/mainnet/0x6a14869266a1dcf3f51b102f44b7af7d0a56f1766e5b1908ac80a6a23dbaf449

Tags：COMBCOMCOMBOPROcombo幣公司WHALECOMcombo幣最新消息Hubble Protocol

Uniswap