2022年1月18日，我們的異常交易監測系統檢測到了針對AnySwap項目（即Multichain）的攻擊。由於anySwapOutUnderlyingWithPermit()函數未能正確地實現相關校驗機制，導致用戶授權給該項目的token可被攻擊者取出，關於漏洞細節和相關處置詳情可參考項目方的官方說明（https://medium. com/multichainorg/multichain-contract-vulnerability-post-mortem-d37bfab237c8）。
儘管項目方嘗試了多種方法試圖提醒受影響的用戶（如發送交易提醒，圖1所示），仍然有很多用戶未能及時響應（撤回自己的授權），攻擊者得以持續地實施攻擊獲利。
由於攻擊持續進行，為了保護潛在的受害者，BlockSec團隊決定採取應急響應措施。本次救援特別針對以太坊（Ethereum）上受到影響的賬戶，與之關聯的項目方合約地址為0x6b7a87899490EcE95443e979cA9485CBE7E71522，我們將相關的賬戶資金轉移到我們專門設立的多簽白帽賬戶中(0xd186540FbCc460f6a3A9e705DC6d2406cBcc1C47)。
為了保證行動的透明性，我們將相關行動計劃在pdf文件中做了說明，並立即將文件hash（而非內容）向社區公開。這樣既能夠保證將我們的行為與攻擊者行為做區分，也不會洩漏任何細節（因為攻擊仍在持續）。
我們的救援行動從2022年1月21日正式開始，到2022年3月11日正式結束，相關的公開聲明分別如圖2、圖3所示。
應急救援並非是一件容易達成的任務，有各種技術和非技術方面的挑戰需要克服。由於行動已經結束，我們得以重新復盤整個過程，並將相關心得與體會與社區分享。我們希望也相信這樣的分享對社區，以及DeFi生態的安全會有所幫助。
簡要總結（太長不看版）
不同陣營的參與者對Flashbots的廣泛使用產生了激烈競爭，包括白帽和攻擊者兩個群體之間，乃至各自群體內部，向Flashbots支付的費用也隨著時間的推移迅速增長。
Flashbots不是萬靈丹，並非總是有效。有些攻擊者轉而使用mempool，通過巧妙的策略安排了攻擊交易，成功實施了攻擊。
某些攻擊者與項目方達成協議，歸還部分攻擊所得，保留部分攻擊所得作為獎賞，得以成功洗白。這種現像不是第一次出現，其激勵的公平性也在社區內部引起了很大的爭議和討論。
從透明性考量，白帽可以在不洩露敏感信息的同時向社區公開宣告自己的行為，這樣取信於社區的方式在實踐中表現良好。
二級標題
一級標題
二級標題
0x1.1 總體結果
二級標題
二級標題
0x1.2 Flashbots費用的變化趨勢
二級標題
一級標題
二級標題
0x2.1 我們如何開展救援行動？
救援的基本思路是簡單而直接的。具體而言，我們需要監控一批潛在的受害者賬戶，這些賬戶已將WETH授權給有問題的項目方合約使用。當有任何的WETH轉賬進入該賬戶，我們利用合約漏洞直接將其轉出至我們的白帽多簽錢包。這裡的關鍵是要滿足以下三個要求：
R1: 有效地定位轉賬給受害者賬戶的交易，為方便敘述，以下我們將這些交易命名為轉賬交易（transferred TXs）。
R2: 正確地構造交易實施拯救，為方便敘述，以下我們將這些交易命名為拯救交易（rescue TXs）。
R3: 成功地搶跑攻擊者（或其它第三方）交易，為方便敘述，以下我們將這些交易命名為攻擊交易（attack TXs ）。
二級標題
二級標題
0x2.2 我們捲入的競爭
二級標題
一級標題
二級標題
0x3.1 如何確定Flashbots費用？
在整個救援過程中，我們先後被12個同樣利用Flashbots的競爭者擊敗，包括2個救援賬戶和10個攻擊賬戶。
我們設置Flashbots費用的策略相對而言是較為保守的。具體而言，為了保護受害者的利益，我們總是傾向於盡可能較少地設置Flashbots費用。因此除非已經有成功地使用Flashbots的攻擊交易出現，我們並不會主動地使用Flashbots或增加Flashbots費用。比如一個成功的攻擊交易設置的Flashbots費用比例為10%，我們可能會在下一次救援交易中將之設置為11%。但是，結果證明這樣的策略並不太成功，攻擊者（甚至一些白帽）通常會採用較為激進的策略設置費用以贏得競爭，例如：
圖5展示了區塊高度為14071986的一筆攻擊交易，攻擊者0x5738** 將比例設置為70%。
圖6展示了區塊高度為14072255的一筆攻擊交易，白帽0x14ca** 將比例設置為79%。
圖7展示了區塊高度為14072385的一筆攻擊交易，白帽0x14ca** 將比例設置為80%。
圖8展示了區塊高度為14072417的一筆攻擊交易，白帽0x9117** 將比例設置為81%。
一級標題
一級標題
0x3.2 如何在mempool中正確地安排交易位置？
目前看起來救援成功與否依賴於Flashbots費用的軍備競賽。然而我們確實發現，由於多個參與方引發的激烈競爭的存在，使得Flashbots並非總是有效，這裡的激烈競爭來自於和攻擊/救援無關的其它交易發送方，比如套利等。在這種情況下，即便某個攻擊交易所設置的最高（相較於其它攻擊和救援交易）Flashbots費用，都無法保證贏得Flashbots競爭。
另一個可行的方法是使用通過mempool發送正常交易，如果交易被安排在合適的位置，也有可能實現目標。這里合適的位置指的是攻擊/救援交易位於轉賬交易之後，且非常接近轉賬交易（越近越好，如果恰好處在轉賬交易的下一個位置則最為理想）。事實上，攻擊者0x48e9**運用這樣的策略成功的收割了312.014657 ETH，且並沒有付出任何Flashbots費用的成本。以下四幅圖展示了該攻擊者獲利最高的兩次攻擊：
圖10和圖11分別展示了在區塊高度14051020，受害者0x3acb**的轉賬交易（轉入50 ETH）位於65，而攻擊交易（獲利50 ETH）位於66。
二級標題
一級標題
二級標題
0x4.1 如何區分白帽和攻擊者？
識別白帽及其行為可能並不像一般人認為的那樣簡單直白。舉例來說，賬戶地址0xfa27被Etherscan.io標記為白帽：Multichain Exploiter 4 (Whitehat)。然而在一開始的時候，這個地址被標記為攻擊者：Multichain Exploiter 4。這裡的變化來自於項目方和攻擊者的互動， 在若干輪協商之後，攻擊者同意保留50 ETH的獲利作為獎賞，返還其它獲利（扣除Flashbots費用等）：
在交易0x3c3d**中，項目方聯繫該攻擊者:
在交易0xd360**中，攻擊者回复：
二級標題
二級標題
二級標題
二級標題
0x4.3 如何更好地開展救援行動？
一方面，從透明性考量，白帽可以在不洩露敏感信息的同時向社區公開宣告自己的行為，這樣取信於社區的方式在實踐中表現良好。與針對某個特別攻擊的阻斷（blocking）任務相比，這樣的救援（rescuing）行動通常是拉鋸戰，白帽和攻擊者之間會在一段時間內交手多次，因此會有充足的時間做宣告。當然，在剛開始行動的時候，漏洞相關的細節信息並不需要披露，以免造成不必要的危害（但記錄行動意圖的文件hash可以與社區共享，如同我們在此次救援中所做的那樣） ；在行動結束後，這些信息應該向社區充分公開。
另一方面，社區的各方力量可以攜手合作，使得救援行動更為迅速和有效，包括但不限於：
Flashbots/Miners向認證過且可信的白帽提供綠色通道，既可用於搶跑攻擊交易，也能避免白帽間的競爭。
被攻擊的項目方負責Flashbots費用的成本。
項目方採用更為方便和快捷的機制及時向用戶預警。
項目方在代碼中採用一些必要的應急措施。
