與時間和策略的賽跑：關於 AnySwap 的救援行動與我們的經驗教訓

1 月 18 日，我們的監控系統偵測到針對 AnySwap 項目（又稱 Multichain）的攻擊。該漏洞源於 anySwapOutUnderlyingWithPermit() 函數，其驗證機制可被繞過，進而導致已授權的代幣被提取。

儘管該項目採取了不同的方式（例如，向用戶發送交易，如圖 1 所示）來通知受影響的用戶，但仍有許多用戶未能及時採取行動（即撤銷授權）來保護其資金。結果，攻擊者得以持續發動攻擊以獲取受害者的資金。

為了保護潛在的受害者，在經過審慎考慮後，我們的團隊決定對以太坊上 AnySwap 的脆弱合約 (0x6b7a87899490EcE95443e979cA9485CBE7E71522) 進行緊急救援。具體來說，我們可以將脆弱帳戶的資金轉移到我們的白帽錢包，這是一個位於以太坊上的多重簽名錢包 (0xd186540FbCc460f6a3A9e705DC6d2406cBcc1C47)。

為了使我們的白帽救援透明化，我們將意圖記錄在 PDF 文件中，並與社群分享了文件哈希值。這既能將我們的緊急救援與攻擊區分開來，同時也不會洩露漏洞細節（因為該漏洞仍可被利用）。我們於 2022 年 1 月 21 日至 2022 年 3 月 11 日展開了緊急救援，並向公眾發布了相應的訊息，如下所示：

緊急救援並非易事。事實上，在執行成功的救援過程中存在多項技術與非技術層面的挑戰。由於緊急救援已經結束，我們可以對整個過程進行全面回顧，並分享我們學到的教訓。我們相信這些經驗能為確保 DeFi 生態系統的安全提供一些啟示。

重點摘要 (TL;DR)

• 不同參與者之間存在競爭，包括白帽駭客與攻擊者。隨著時間推移，支付給 Flashbots 的費用迅速增加。
• Flashbots 並非總是有效。相反，一些攻擊者轉而採用正常的記憶體池（mempool），透過採取複雜的策略成功發動攻擊。
• 一些攻擊者透過歸還部分被盜資金而「洗白」，剩餘部分則作為賞金保留。這種現象雖然不是第一次出現，但在社群中頗具爭議，因為這種激勵機制對真正的白帽駭客可能並不公平。
• 為了取信於社群，白帽駭客採取行動前先公開預告且不洩露任何敏感細節，是一種良好的做法。
• 社群可以共同合作，更有效率地執行救援。例如，建立協調機制來減少或避免白帽駭客之間的競爭。

接下來，我們首先提供救援期間的整體情況，隨後說明我們執行救援的方式以及需要解決的挑戰，接著討論我們從中學到的教訓。最後，我們提供一些可能有助於確保生態系統安全的想法與建議。

0x1 救援與攻擊

0x1.1 整體結果

本報告中我們觀察並調查的攻擊與救援持續了數月，範圍從區塊 14028474（2022 年 1 月 18 日）到區塊 14421215（2022 年 3 月 20 日）。

執行救援與攻擊的帳戶總結如下表。為簡單起見，僅顯示地址的前四位以代表 EOA（外部擁有帳戶）。 帳戶類型分為救援帳戶或攻擊帳戶。值得注意的是，帳戶類型是基於 Etherscan.io 的標記或我們觀察到的轉移目標地址來確定的。

總共有 9 個救援帳戶成功救援了 483.027693 ETH（費用為 295.970554 ETH，即總金額的 61.27%），以及 21 個攻擊帳戶竊取了 1433.092224 ETH（費用為 148.903707 ETH，即總金額的 10.39%）。需要注意的是，由於互動情況複雜，損失金額僅為粗略估計。例如，攻擊帳戶在與 AnySwap 協商後可能會轉變為救援帳戶，我們稍後會討論這種現象。表格的最後一欄顯示了發送給礦工的費用，這些費用用於贏得 Flashbots 的使用競爭。

0x1.2 競標 Flashbots 的費用趨勢

如前所述，白帽駭客需要與攻擊者競爭發送交易。因此，支付給礦工的費用百分比（在 Flashbots 交易中）可以反映競爭程度。為了進行定量測量，我們調查了每個區塊的費用百分比（分別包括攻擊交易和救援交易）。

圖 4 展示了我們目前觀察到的趨勢（從區塊 14028474 到 14369199）。 最初的幾筆攻擊交易不涉及任何費用，這意味著在此期間幾乎沒有（甚至沒有）競爭。這是合理的，因為這些早期的攻擊可能還不為人所知。

事實上，第一筆附帶費用的攻擊發生在區塊 14029765（費用為 10%）。 此後，隨著越來越多的參與者加入，費用百分比迅速增加。 例如，該百分比在區塊 14072385 時達到 80%，隨後在區塊 14129449 時達到 91%。

簡而言之，這一趨勢表明，為了贏得競爭而增加給礦工的費用，這絕無疑問是一場軍備競賽。

0x2 我們的救援與挑戰

0x2.1 執行救援的方式

執行救援的基本思路非常直接。具體而言，我們需要監控那些已向脆弱合約授權 WETH 的帳戶。當有任何 WETH 轉入這些帳戶時，我們就能利用該脆弱的 AnySwap 合約直接將其轉移到我們的多重簽名錢包中。關鍵要求是：

• R1：有效定位那些將代幣轉入受害者帳戶的交易。我們在下文中將這些交易稱為轉移交易 (transferred TXs)。
• R2：正確建構執行救援的交易。我們在下文中將這些交易稱為救援交易 (rescue TXs)。
• R3：成功搶先（frontrun）攻擊者（以及任何其他第三方）發送的交易。我們在下文中將這些交易稱為攻擊交易 (attack TXs)。

R1 和 R2 對我們來說不是障礙。具體來說，我們建立了一個監控記憶體池的內部系統，這使我們能夠及時定位轉移交易。同時，我們也開發了一種工具來自動建構交易。

然而，R3 依然是一項挑戰。人們可能會認為可以使用 Flashbots 來贏得競爭，但要達到目標並不容易。首先，攻擊者也可能使用 Flashbots。作為一個費用競標系統，成功率可能取決於支付給礦工的費用，設定費用的策略需要詳加考量。其次，由於競爭激烈，使用 Flashbots 可能並非最佳選擇。因此，我們也透過記憶體池發送普通交易。為了保證成功，必須考慮如何將交易放置在正確的位置。最後，我們還要與其他白帽駭客抗衡，他們在某些情況下的行為似乎很可疑。

0x2.2 我們參與的競爭

總計，我們試圖保護 171 位潛在受害者，其中 10 位在我們嘗試救援前就透過撤銷授權自行進行了保護。對於剩餘的 161 位有效受害者，由於激烈的競爭，我們僅成功救援了其中 14 位。失敗案例總結在下表中，涉及 3 個救援帳戶和 16 個攻擊帳戶。

因此，我們有一些教訓願意與社群分享。

0x3 我們學到的教訓

0x3.1 如何確定 Flashbots 礦工的費用金額？

總結來說，我們被 12 個競爭對手擊敗，其中包括 2 個使用 Flashbots 的救援帳戶和 10 個攻擊帳戶。

我們設定礦工費用的策略相當保守。具體而言，我們希望透過儘量減少費用來保護受害者。因此，除非已有成功的攻擊交易設定了費用，否則我們不會積極使用或增加費用。例如，如果有攻擊者將費用設定為資金的 10%，我們可能會在下一次救援中設定 11% 來與之競爭。 然而，結果表明這種策略並不奏效，因為攻擊者（甚至一些白帽駭客）通常會積極提高費用來擊敗對手，如下所示：

• 圖 5 顯示攻擊者 0x5738** 在區塊 14071986 將費用百分比設定為 70%。
• 圖 6 顯示白帽駭客 0x14ca** 在區塊 14072255 將費用百分比設定為 79%。
• 圖 7 顯示白帽駭客 0x14ca** 在區塊 14072385 將費用百分比設定為 80%。
• 圖 8 顯示白帽駭客 0x9117** 在區塊 14072417 將費用百分比設定為 81%。
• 圖 9 顯示攻擊者 0x5738** 在區塊 14073395 將費用百分比設定為 86%。

簡而言之，這似乎是一場零和博弈，需要對不同參與者的行為進行建模才能贏得競爭。

然而在實踐中，如何找到更好或最優的策略，同時儘量降低成本，是一項挑戰。

0x3.2 如何在記憶體池中放置正確的位置？

現在救援過程似乎已演變為 Flashbots 競標的軍備競賽。 然而，我們發現由於來自其他參與者的激烈競爭（這與救援或攻擊無關），使用 Flashbots 並非靈丹妙藥。在這種情況下，即使是攻擊交易中設定的最高費用也無法保證贏得使用 Flashbots 的機會。

或者，在記憶體池中擁有正確位置的普通交易可能有機會實現目標。此處的「正確位置」是指救援/攻擊交易應部署在轉移交易之後，且位置應非常接近（越近越好）。請注意，透過此策略，攻擊者 0x48e9** 在未向 Flashbots 礦工支付任何費用的情況下竊取了 312.014657 ETH。

以下四張圖展示了該攻擊者獲利最高的兩次案例：

• 圖 10 顯示受害者在區塊 14051020 的位置 65 存入了 50 ETH，而圖 11 顯示攻擊者在同一區塊的位置 66 竊取了這 50 ETH。
• 圖 12 顯示受害者在區塊 14052155 的位置 161 存入了 200 ETH，而圖 13 顯示攻擊者在同一區塊的位置 164 竊取了這 200 ETH。

顯然，這種複雜的策略非常有用且具有啟發性，值得我們投入更多關注與精力來學習。

0x4 其他想法

0x4.1 白帽駭客行為還是攻擊？

說到對「白帽駭客行為」的認定，情況可能並不像人們想像的那麼簡單。

例如，地址 0xfa27 被 Etherscan.io 標記為 Multichain Exploiter 4 (Whitehat)。實際上最初它被標記為 Multichain Exploiter 4。在攻擊者與 AnySwap 項目方經過幾輪談判後，攻擊者被說服歸還了部分被盜資金。

• 在交易 0x3c3d** 中，AnySwap 聯繫了攻擊者：

首先最重要的是謝謝你拿到了 WETH。我並不知道這次駭客攻擊，只是意識到在 CowSwap 交易後 WETH 沒有到我的錢包，才發現了這種情況。考慮到涉及的金額，你願意接受 50 ETH 作為合理的報酬嗎？ 這是我的交易資訊： 0x2db9a6a51604e2be8b2c3469773afb201f0b48a318fb7e5f5e49175e818df5ba 0xe50ed602bd916fc304d53c4fed236698b71691a95774ff0aeeb74b699c6227f7

• 在交易 0xd360** 中，攻擊者回覆：

請發送一筆交易給我以進行確認。我會發給你剩下的 258 ETH。有 39 ETH 給了礦工，因為還有其他攻擊者，我必須支付那筆小費來挽救資金。

• 在交易 0x354f** 中，AnySwap 在收到資金後表達了感謝：

已收到，感謝你的誠實。

顯然，這位攻擊者被「洗白」了，而且還從攻擊中獲取了一些利潤。 類似的案例過去發生過多次，在社群中仍具爭議，因為這類激勵機制可能並不公平。

0x4.2 白帽駭客之間的競爭？

建立一個協調機制以減少或避免白帽駭客之間的競爭是必要的。這種競爭不可避免地導致了救援力量的浪費。 在此次救援中，有 54 位受害者（涉及 450 ETH 資金）是由其他三位白帽駭客保護的，而我們也試圖對其進行救援。

白帽駭客之間的競爭不僅浪費了救援力量，還提高了執行救援的成本。例如，如圖 7 和圖 8 所示，兩位不同白帽駭客的救援交易分別花費了 80% 和 81% 的費用。

遺憾的是，除非存在某種協調機制，否則白帽駭客不會退讓。否則，這種競爭是不可能消失的。

0x4.3 如何做得更好？

一方面，為了取信於社群，白帽駭客採取行動前先公開預告且不洩露任何敏感細節，是一種良好的做法。 通常有足夠的時間這麼做，因為救援通常是一場反覆嘗試的拉鋸戰，這與封鎖特定攻擊等一次性行動不同。當然，涉及漏洞的詳細資訊不應洩露。

為了實現這一點，我們可以在行動初期不披露詳情，在完成救援後再向社群披露，就像我們對待 AnySwap 救援所做的那樣。不過，我們可以與社群分享包含白帽駭客意圖的文件哈希值。

另一方面，社群可以做更多事情來更有效地執行救援，包括但不限於：

• Flashbots 或礦工可以為經過認證的白帽駭客提供「綠色通道」。綠色通道可以提供高優先級搶在攻擊者交易之前，並避免白帽駭客之間的競爭。
• 被攻擊的項目方承擔 Flashbots 或礦工的費用。
• 項目方可以向用戶應用便捷、快速的通知機制。
• 項目方可以在程式碼中應用緊急處理機制。

關於 BlockSec

BlockSec 是一家開創性的區塊鏈安全公司，由一群全球知名的安全專家於 2021 年成立。公司致力於提升新興 Web3 世界的安全性和可用性，以促進其大規模採用。為此，BlockSec 提供智慧合約與 EVM 鏈的安全審計服務、用於安全開發與主動防禦威脅的 Phalcon 平台、用於資金追蹤與調查的 MetaSleuth 平台，以及協助 Web3 構建者在加密世界中高效探索的 MetaSuites 擴充功能。

迄今為止，公司已為 MetaMask、Uniswap Foundation、Compound、Forta 和 PancakeSwap 等 300 多家知名客戶提供服務，並獲得了涵蓋 Matrix Partners、Vitalbridge Capital 和分佈式資本（Fenbushi Capital）等頂尖投資機構的兩輪千萬美元級別融資。

官方網站：https://blocksec.com/

官方 Twitter 帳號：https://twitter.com/BlockSecTeam