Multichain項目漏洞攻防分析:從應急救援看Web3生態安全

2022年1月18日,我們的異常交易監測系統發現了針對Multichain項目的攻擊。由於相關函數未能正確實現校驗機制,導致用戶授權給該項目的token可被攻擊者取出。

雖然項目方嘗試通過多種方式提醒受影響用戶,仍有許多用戶未能及時響應,攻擊者得以持續實施攻擊獲利。

鑑於攻擊持續進行,爲保護潛在受害者,我們決定採取應急響應措施。本次救援針對以太坊上受影響的帳戶,我們將相關帳戶資金轉移到專門設立的多籤白帽帳戶中。爲保證行動透明,我們將相關計劃的文件哈希值(而非內容)向社區公開。我們的救援行動從2022年1月21日開始,到2022年3月11日結束。

應急救援面臨諸多技術和非技術挑戰。現在行動已結束,我們得以重新復盤整個過程,並將相關心得與社區分享。我們希望這樣的分享對社區及DeFi生態的安全有所幫助。

簡要總結

• 不同參與者對Flashbots的廣泛使用產生了激烈競爭,包括白帽和攻擊者兩個羣體之間及各自羣體內部,向Flashbots支付的費用也隨時間迅速增長。

• Flashbots並非總是有效。部分攻擊者轉而使用mempool,通過巧妙策略安排攻擊交易,成功實施攻擊。

• 某些攻擊者與項目方達成協議,歸還部分攻擊所得,保留部分作爲獎賞,得以成功"洗白"。這種現象引發了社區對其激勵公平性的爭議和討論。

• 從透明性考量,白帽可在不泄露敏感信息的同時向社區宣告自身行爲,這種取信於社區的方式在實踐中表現良好。

• 社區各方力量可攜手合作,使救援行動更爲迅速和有效。例如可在白帽之間開展協同,減少或避免無效競爭。

攻擊和救援情況概覽

總體結果

在我們觀察範圍內(2022年1月18日至2022年3月20日),總體攻擊和救援情況如下:

• 9個救援帳戶保護了483.027693 ETH,其中支付給Flashbots費用爲295.970554 ETH(佔比61.27%)
• 21個攻擊帳戶獲利1433.092224 ETH,其中支付給Flashbots費用爲148.903707 ETH(佔比10.39%)

值得注意的是,由於存在一些復雜交互情況(如某些攻擊者與項目方協商後返還部分獲利,相關地址標籤可能變化),上述數據僅爲大致統計。

Flashbots費用的變化趨勢

白帽需要和攻擊者競爭發送Flashbots交易來實施救援,支付給Flashbots的費用變化趨勢可反映競爭激烈程度。我們按交易區塊,對攻擊和救援交易分別統計了Flashbots費用佔比。

分析表明,早期攻擊交易的Flashbots費用爲0,表示當時攻擊者尚未使用Flashbots。隨後Flashbots費用佔比快速上升,在某些區塊甚至達到80%-91%。這一趨勢反映了由於Flashbots上鏈權之爭而導致的費用軍備競賽。

我們實施的救援行動和面臨的挑戰

救援行動的基本思路

我們的救援思路是監控一批潛在受害者帳戶,這些帳戶已將WETH授權給有問題的項目合約。當有WETH轉入該帳戶時,我們利用合約漏洞將其轉出至白帽多簽錢包。關鍵是要滿足以下要求:

1. 有效定位轉帳給受害者帳戶的交易(轉帳交易)
2. 正確構造交易實施拯救(拯救交易)
3. 成功搶跑攻擊者(或其它第三方)交易(攻擊交易)

前兩項要求對我們而言不構成阻礙。然而第三項仍然是一個挑戰,即便使用Flashbots也不總能保證成功。我們還需考慮費用設置策略、交易在mempool中的位置和順序等因素。

競爭情況

我們嘗試保護171個獨立的潛在受害者帳戶。其中10個及時撤銷授權實現了自我保護,在餘下的161個帳戶中,由於各類競爭的存在,我們僅成功救援了14個。失敗情況涉及3個救援帳戶和16個攻擊帳戶。

經驗教訓

Flashbots費用設置策略

在救援過程中,我們先後被12個使用Flashbots的競爭者擊敗,包括2個救援帳戶和10個攻擊帳戶。

我們的Flashbots費用設置策略較爲保守,傾向於盡可能少地設置費用以保護受害者利益。然而實踐證明這樣的策略並不太成功,攻擊者(甚至部分白帽)通常採用更激進的策略設置費用以贏得競爭。

我們觀察到的一些案例顯示,競爭者將Flashbots費用比例設置在70%-86%之間。這似乎是一個零和遊戲,需要建模來探索各參與方的行爲模式。在實踐中,既要盡可能降低代價,又要找到較優策略贏得競爭,是一項具有挑戰性的任務。

Mempool交易安排策略

由於多方引發的激烈競爭,Flashbots並非總是有效。在這種情況下,即便設置最高的Flashbots費用,也無法保證贏得競爭。

另一個可行方法是通過mempool發送普通交易,如果交易被安排在合適位置(即緊跟在轉帳交易之後),也可能實現目標。我們觀察到一個攻擊者運用這種策略成功獲利312 ETH,且未支付任何Flashbots費用。

這種巧妙策略兼具實用性和啓發性,值得關注和學習。

其他思考

白帽與攻擊者的界定

識別白帽及其行爲可能並不簡單直白。我們觀察到一個案例,某地址最初被標記爲攻擊者,後來被重新標記爲白帽。這源於該地址與項目方達成協議,同意保留部分獲利作爲獎賞,返還其他獲利。

這種現象不是首次出現,其激勵的公平性在社區內引發了較大爭議和討論。

白帽間的協調機制

社區有必要建立溝通協調機制來降低/避免白帽之間的競爭。這種競爭不僅會浪費救援資源,還會提高救援成本。例如,在本次救援中,我們和其他三個白帽(組織)同時試圖保護54個受害者(涉及450 ETH損失)。

如果沒有相應協調機制,白帽們難以放棄/停止這樣的競爭。

改進救援行動的建議

1. 白帽可在不泄露敏感信息的同時向社區公開宣告自身行爲,以取信於社區。

2. 社區各方力量可攜手合作,使救援更爲迅速和有效:

   • Flashbots/礦工可向認證的可信白帽提供綠色通道
   • 被攻擊項目方承擔Flashbots費用成本
   • 項目方採用更便捷的機制及時向用戶預警
   • 項目方在代碼中採取必要的應急措施

通過各方協作,我們有望構建一個更安全、更高效的Web3生態系統。