項目漏洞救援行動回顧與思考

2022年1月18日，我們的異常交易監測系統發現了針對某跨鏈項目的攻擊。由於項目合約中的一個函數未正確實施校驗機制，導致用戶授權給該項目的代幣可被攻擊者提取。

盡管項目方嘗試多種方式提醒受影響用戶,仍有許多用戶未能及時響應,攻擊者得以持續實施攻擊獲利。鑑於攻擊持續進行,爲保護潛在受害者,我們決定採取應急響應措施。本次救援針對以太坊上受影響的帳戶,我們將相關帳戶資金轉移到專門設立的多籤白帽帳戶中。爲確保行動透明,我們將相關計劃的文件哈希向社區公開,既區分了我們與攻擊者的行爲,又不會泄露細節。救援行動從2022年1月21日開始,3月11日結束。

應急救援面臨諸多技術和非技術挑戰。行動結束後,我們復盤了整個過程,希望分享相關經驗,爲社區和DeFi生態安全提供幫助。

救援情況概述

在我們觀察的時間範圍內(2022年1月18日至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轉入時,利用合約漏洞將其轉出至白帽多簽錢包。關鍵是要滿足以下要求:

1. 有效定位轉帳給受害者的交易
2. 正確構造拯救交易
3. 成功搶跑攻擊者交易

前兩項對我們而言不構成障礙,但第三項仍具挑戰性。雖然可用Flashbots搶跑,但由於採用費用競拍模式,成功率取決於費用高低,策略設置需額外考量。此外,mempool發送普通交易時交易位置和順序也是關鍵因素。我們還與其他"白帽"產生了競爭,部分"白帽"行爲較爲可疑。

總體而言,我們試圖保護171個潛在受害帳戶。其中10個及時撤銷授權自我保護,在剩餘161個中,由於各類競爭存在,我們僅成功救援14個。

經驗教訓

Flashbots費用設置

我們的費用策略較爲保守,傾向於設置較低費用以保護受害者利益。然而這種策略並不太成功,攻擊者和部分白帽通常採用更激進策略。例如:

• 某攻擊者將費用比例設爲70%
• 某白帽將費用比例設爲79%-81%
• 另一攻擊者將費用比例提高到86%

這似乎成爲一個零和遊戲,需要建模探索各方行爲模式,在降低成本和贏得競爭間尋求平衡。

Mempool交易排序

由於多方激烈競爭,Flashbots並非總有效。使用mempool發送普通交易,如果安排在合適位置,也可能實現目標。一名攻擊者運用這種策略成功獲利312 ETH,且無需支付Flashbots費用。

其攻擊交易巧妙地安排在受害者轉帳交易之後的相鄰位置。這種策略兼具實用性和啓發性,值得關注。

其他思考

白帽與攻擊者的界定

識別白帽並非總是簡單直白。例如,某地址最初被標記爲攻擊者,後來改爲白帽。這源於項目方與攻擊者協商,攻擊者同意保留部分獲利作爲獎賞並返還其他獲利。這種現象在社區引發了對激勵公平性的討論。

白帽間競爭

社區有必要建立協調機制以減少白帽間競爭。這種競爭會浪費救援資源,提高救援成本。例如,我們與其他三個白帽組織同時試圖保護54個受害者,涉及450 ETH損失。

改進救援行動

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

2. 社區各方可攜手合作,使救援更快速有效:

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

通過總結經驗教訓,我們希望未來的救援行動能更加高效,最大程度保護用戶利益。