慢霧：Furucombo被黑分析_UCO

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

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

慢霧：仍有大部分錢包支持eth_sign，僅少部分錢包提供安全風險警告:金色財經報道，在加密貨幣NFT板塊，越來越多的釣魚網站濫用 eth_sign 簽名功能來進行盲簽欺詐，提醒或禁用這種低級的簽名方法對于保護用戶安全是至關重要的，不少 Web3 錢包已經采取相關措施來對這種危險的簽名方法進行安全提示和限制。仍有一大部分加密錢包支持 eth_sign，其中少部分錢包提供 eth_sign 安全風險警告。如果用戶仍想要使用 eth_sign，他們可以選擇支持該功能的加密錢包。但是，用戶在使用這些錢包時需要特別注意安全警告，以確保其交易的安全性。[2023/5/11 14:57:14]

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

慢霧：GenomesDAO被黑簡析:據慢霧區hacktivist消息，MATIC上@GenomesDAO項目遭受黑客攻擊，導致其LPSTAKING合約中資金被非預期的取出。慢霧安全團隊進行分析有以下原因：

1.由于GenomesDAO的LPSTAKING合約的initialized函數公開可調用且無權限與不可能重復初始化限制，攻擊者利用initialized函數將合約的stakingToken設置為攻擊者創建的虛假LP代幣。

2.隨后攻擊者通過stake函數進行虛假LP代幣的抵押操作，以獲得大量的LPSTAKING抵押憑證。

3.獲得憑證后再次通過initialized函數將合約的stakingToken設置為原先真是的LP代幣，隨后通過withdraw函數銷毀LPSTAKING憑證獲取合約中真實的LP抵押物。

4.最后將LP發送至DEX中移除流動性獲利。

本次事件是因為GenomesDAO的LPSTAKING合約可被任意重復初始化設置關鍵參數而導致合約中的抵押物被惡意耗盡。[2022/8/7 12:07:06]

慢霧：Ribbon Finance遭遇DNS攻擊，某用戶損失16.5 WBTC:6月24日消息，Ribbon Finance 發推表示遭遇 DNS 攻擊，慢霧MistTrack通過鏈上分析發現攻擊者與今天早前的Convex Finance 攻擊者是同一個，地址 0xb73261481064f717a63e6f295d917c28385af9aa 是攻擊者共用的用來調用惡意合約的錢包地址。同時分析發現，Ribbon Finance某用戶在攻擊中損失了 16.5 WBTC，具體交易為：https://etherscan.io/tx/0xd09057f1fdb3fa97d0ed7e8ebd8fd31dd9a0b5b61a29a22b46985d6217510850。[2022/6/24 1:29:35]

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

慢霧：Crosswise遭受攻擊因setTrustedForwarder函數未做權限限制:據慢霧區情報，2022年1月18日，bsc鏈上Crosswise項目遭受攻擊。慢霧安全團隊進行分析后表示，此次攻擊是由于setTrustedForwarder函數未做權限限制，且在獲取調用者地址的函數_msg.sender()中，寫了一個特殊的判斷，導致后續owner權限被轉移以及后續對池子的攻擊利用。[2022/1/19 8:57:48]

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

聲音 | 慢霧：Dapp、交易所等攻擊事件造成損失已近41億美金:慢霧數據顯示Dapp、交易所等攻擊事件造成的損失已達4098587697.68美金，半月增加近3億美金。據2月28日報道，慢霧區上線“被黑檔案庫(SlowMist Hacked)”，目前各類攻擊事件共造成約 3824082630.12 美金的損失。[2019/3/13]

這里有一個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：COMCOMBUCOFURCOMP幣combo幣發行價kucoin官網下載Furukuru

歐易okex官網