慢霧：Furucombo被黑分析_FUR

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

攻擊細節分析

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

慢霧：Rubic協議錯將USDC添至Router白名單，導致已授權合約用戶USDC遭竊取:12月25日消息，據慢霧安全團隊情報，Rubic跨鏈聚合器項目遭到攻擊，導致用戶賬戶中的USDC被竊取。慢霧安全團隊分享如下：1. Rubic是一個DEX跨鏈聚合器，用戶可以通過RubicProxy合約中的routerCallNative函數進行Native Token兌換。在進行兌換前，會先檢查用戶傳入的所需調用的目標 Router是否在協議的白名單中。

2. 經過白名單檢查后才會對用戶傳入的目標Router進行調用，調用數據也由用戶外部傳入。

3. 不幸的是USDC也被添加到Rubic協議的Router白名單中，因此任意用戶都可以通過RubicProxy合約任意調用USDC。

4. 惡意用戶利用此問題通過routerCallNative函數調用USDC合約將已授權給RubicProxy合約的用戶的USDC通過transferFrom接口轉移至惡意用戶賬戶中。

此次攻擊的根本原因在于Rubic協議錯誤的將USDC添加進Router白名單中，導致已授權給RubicProxy合約的用戶的USDC被竊取。[2022/12/26 22:07:00]

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

慢霧：靚號黑客已獲取到ParaSwap Deployer和QANplatform Deployer私鑰權限:10月11日消息，據慢霧區情報，靚號黑客地址之一（0xf358..7036）已經獲取到ParaSwap Deployer和QANplatform Deployer私鑰權限。黑客從ParaSwap Deployer地址獲取到約1千美元，并在QANplatform Deployer地址做了轉入轉出測試。慢霧MistTrack對0xf358..7036分析后發現，黑客同樣盜取了The SolaVerse Deployer及其他多個靚號的資金。截止目前，黑客已經接收到超過17萬美元的資金，資金沒有進一步轉移，地址痕跡有Uniswap V3、Curve、TraderJoe，PancakeSwap、OpenSea和Matcha。慢霧MistTrack將持續監控黑客地址并分析相關痕跡。[2022/10/11 10:31:05]

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

慢霧：BXH 第一次被盜資金再次轉移，BTC 網絡余額超 2700 BTC:金色財經報道，10月8日凌晨（UTC+8），慢霧監控到 BXH 第一次被盜資金再次出現異動，經慢霧 MistTrack 分析，異動詳情如下：

黑客地址 0x48c9...7d79 將部分資金（213.77 BTCB，5 BNB 和 1 ETH）轉移至新地址 0xc01f...2aef，接著將資金兌換為 renBTC 跨鏈到 BTC 網絡，跨鏈后地址為 1JwQ...u9oU。1JwQ...u9oU 在此次轉移中接收到的總資金為 204.12 BTC。截止目前，BXH 第一次被盜事件在 BTC 網絡共有 4 個黑客地址，總計余額為 2701.3 BTC，暫未進一步轉移。慢霧 MistTrack 將持續監控被盜資金的轉移。[2022/10/8 12:49:28]

慢霧：警惕 Honeyswap 前端被篡改導致 approvals 到惡意地址風險:據慢霧區消息，Honeyswap官方推特發文，Honeyswap 前端錯誤導致交易到惡意地址 “0xD3888a7E6D6A05c6b031F05DdAF3D3dCaB92FC5B” ，目前官網仍未刪除該惡意地址，請立即停止使用Honeyswap進行交易，到revoke.cash排查是否有approvals 交易到惡意地址，避免不必要的損失。[2022/5/10 3:03:22]

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

慢霧：Polkatrain 薅羊毛事故簡析:據慢霧區消息，波卡生態IDO平臺Polkatrain于今早發生事故，慢霧安全團隊第一時間介入分析，并定位到了具體問題。本次出現問題的合約為Polkatrain項目的POLT_LBP合約，該合約有一個swap函數，并存在一個返傭機制，當用戶通過swap函數購買PLOT代幣的時候獲得一定量的返傭，該筆返傭會通過合約里的_update函數調用transferFrom的形式轉發送給用戶。由于_update函數沒有設置一個池子的最多的返傭數量，也未在返傭的時候判斷總返傭金是否用完了，導致惡意的套利者可通過不斷調用swap函數進行代幣兌換來薅取合約的返傭獎勵。慢霧安全團隊提醒DApp項目方在設計AMM兌換機制的時候需充分考慮項目的業務場景及其經濟模型，防止意外情況發生。[2021/4/5 19:46:39]

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

這里有一個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合約。如有授權，應及時撤銷相關授權，避免進一步損失。

Tags：PROFURProxyROXProjectonMetafuryProxyNode

FIL