2022 年 1 月 18 日、異常なトランザクション監視システムが AnySwap プロジェクト (つまりマルチチェーン) に対する攻撃を検出しました。 anySwapOutUnderlyingWithPermit() 関数は関連する検証メカニズムを正しく実装できないため、ユーザーがプロジェクトに許可したトークンが攻撃者によって持ち出される可能性があります。脆弱性の詳細および関連する破棄の詳細については、公式声明を参照してください。プロジェクト パーティー (https://medium.com/multichainorg/multichain-contract-vulnerability-post-mortem-d37bfab237c8)。

プロジェクト関係者は、影響を受けるユーザーに注意を促すためのさまざまな方法 (図 1 に示すトランザクション リマインダーの送信など) を試みましたが、多くのユーザーは依然として時間内に応答 (承認の撤回) できず、攻撃者は引き続き攻撃を実行することができました。攻撃して利益を得る。

攻撃が続く中、BlockSec チームは潜在的な被害者を保護するために緊急対応措置を講じることを決定しました。この救済は特にイーサリアム上の影響を受けたアカウントを対象としています。それに関連付けられたプロジェクト契約アドレスは 0x6b7a87899490EcE95443e979cA9485CBE7E71522 です。関連するアカウントの資金を特別に確立されたマルチ署名のホワイトハット アカウント (0xd186540FbCc460f6a3A9e705DC6d240 6cBcc) に送金します。 1C47）。

行動の透明性を確保するために、関連する行動計画を PDF ファイルで説明し、ファイルのハッシュ (内容ではありません) を直ちにコミュニティに公開しました。これにより、詳細を明らかにすることなく、私たちのアクションと攻撃者のアクションを区別できるようになります (攻撃はまだ進行中であるため)。

私たちの救助活動は 2022 年 1 月 21 日に正式に開始され、2022 年 3 月 11 日に正式に終了します。関連する公式声明をそれぞれ図 2 と図 3 に示します。

緊急救助は簡単な作業ではなく、克服すべき技術的および非技術的なさまざまな課題があります。作戦が終了したため、プロセス全体を見直し、関連する経験や経験をコミュニティと共有することができました。私たちは、このような共有がコミュニティと DeFi エコシステムのセキュリティに役立つことを期待し、信じています。

簡単な概要 (長すぎてバージョンを読むことができません)

• ホワイトハットと攻撃者の両方のグループ、さらにはそれぞれのグループ内を含め、さまざまな陣営の参加者が Flashbot の普及をめぐって激しく競争しており、Flashbot に支払われる料金も時間の経過とともに急速に増加しています。

• Flashbot は万能薬ではなく、常に機能するとは限りません。一部の攻撃者は mempool を利用し、巧妙な戦略を通じて攻撃トランザクションを手配し、攻撃を成功させました。

• 一部の攻撃者は、攻撃収益の一部を返還し、攻撃収益の一部を報酬として保持することでプロジェクト当事者と合意に達し、資金洗浄に成功しました。この現象は初めてではなく、そのインセンティブの公平性もコミュニティ内で大きな論争と議論を引き起こしました。

• 透明性の観点から、ホワイトハットは機密情報を漏らすことなく自らの行動をコミュニティに公に発表することができ、コミュニティの信頼を得るこの方法は実際にうまく機能します。

• コミュニティ内のすべての関係者が協力して、救援活動をより迅速かつ効果的に行うことができます。たとえば、ホワイトハット間の調整を実行して、無効な競争を軽減または回避できます。

最初のレベルのタイトル

副題

0x1.1 の全体的な結果

攻撃または救助に関与したイーサリアムのアカウントアドレス統計によると、私たちの観測範囲内（2022年1月18日のブロック高さ14028474から2022年3月20日のブロック高さ14421215まで）における全体的な攻撃と救助の状況は表1に示されています。 (表示の便宜上、アドレスの上4桁のみを表示しています)。具体的には、アカウント アドレスはレスキュー アカウントか攻撃アカウントのいずれかであり、その種類は Etherscan.io タグと資金移動アドレスに基づいて決定されます。さらに、攻撃と救出のプロセス中に、ホワイトハットと攻撃者の両方が Flashbot を使用して大量のトランザクションを送信したため、採掘者に追加料金を支払う必要があります。これを Flashbot 料金と呼びます。

副題

0x1.2 Flashbot 料金の傾向

前述したように、ホワイトハットは救助を実施するために Flashbot トランザクションを送信するために攻撃者と競合する必要があり、Flashbot に支払われる料金の傾向の変化は競争の激しさを反映している可能性があります。定量的な評価を行うために、攻撃トランザクションとレスキュートランザクションに対する Flashbot の手数料の割合をトランザクションブロックごとにカウントしました。

最初のレベルのタイトル

副題

0x2.1 救助活動はどのように行うのですか?

救助の基本的な考え方はシンプルで簡単です。具体的には、問題のあるプロジェクト パーティの契約で WETH の使用を許可した、潜在的な被害者アカウントのバッチを監視する必要があります。このアカウントに WETH 送金がある場合、契約の抜け穴を利用してホワイトハット マルチシグネチャ ウォレットに直接送金します。ここで重要なのは、次の 3 つの要件を満たすことです。

• R1: 被害者のアカウントに転送されたトランザクションを効果的に特定する 説明の便宜上、以下ではこれらのトランザクションを転送トランザクション (転送 TX) と名付けます。

• R2: レスキューを実装するためのトランザクションを正しく構築する 以下、説明の便宜上、これらのトランザクションをレスキュートランザクション(レスキューTX)と呼ぶことにします。

• R3: 攻撃者 (または他のサードパーティ) のトランザクションのプリエンプションに成功する 説明の便宜上、以下ではこれらのトランザクションを攻撃トランザクション (攻撃 TX) と名付けます。

R1とR2は私たちにとって邪魔ではありません。 mempool を監視する内部システムを構築しているため、転送トランザクションをタイムリーに特定できると同時に、レスキュー トランザクションを自動的に構築するツール セットも開発しました。

副題

0x2.2 私たちが参加している競争

全体として、私たちは 171 の固有の潜在的な被害者アカウントを保護しようとしました。このうち、10 件は期限内に承認を取り消すことで自己保護され、残りの 161 件のアカウントのうち、上記のさまざまなコンテストの存在により、救出に成功したのは 14 件のアカウントのみでした。以下の表に、3 つのレスキュー アカウントと 16 の攻撃アカウントが関与した障害をまとめます。

最初のレベルのタイトル

副題

0x3.1 Flashbot の料金はどうやって決めるのですか?

救助プロセス全体を通じて、私たちは同じく Flashbot を悪用した 12 の競合他社 (2 つの救助アカウントと 10 の攻撃アカウントを含む) に連続して敗北しました。

Flashbot の料金設定に関する当社の戦略は比較的保守的です。具体的には、被害者の利益を保護するために、Flashbot の料金を可能な限り低く設定することを常に好みます。したがって、Flashbot を使用した攻撃が成功しない限り、Flashbot を積極的に使用したり、Flashbot の料金を値上げしたりすることはありません。たとえば、攻撃トランザクションが成功すると、Flashbot の手数料率が 10% に設定され、次のレスキュー トランザクションでは 11% に設定される可能性があります。ただし、そのような戦術はそれほど成功しているとは証明されておらず、攻撃者 (一部のホワイト ハットでさえも) は、競争に勝つために料金を設定する次のようなより攻撃的な戦術に頼ることがよくあります。

• 図 5 は、ブロック高さ 14071986 での攻撃トランザクションを示しており、攻撃者 0x5738** は比率を 70% に設定しました。

• 図 6 は、ブロック高さ 14072255 での攻撃トランザクションを示しており、ホワイト ハット 0x14ca** はその割合を 79% に設定しています。

• 図 7 は、ブロック高さ 14072385 での攻撃トランザクションを示しており、ホワイト ハット 0x14ca** は比率を 80% に設定しています。

• 図 8 は、ブロック高さ 14072417 での攻撃トランザクションを示しており、ホワイト ハット 0x9117** によって割合が 81% に設定されています。

• 図 9 は、ブロック高さ 14073395 での攻撃トランザクションを示しており、攻撃者 0x5738** は比率を 86% に設定しました。

最初のレベルのタイトル

0x3.2 mempool 内のトランザクション位置を正しく配置するにはどうすればよいですか?

現在のところ、救出の成功はフラッシュボットのコストをめぐる軍拡競争にかかっているようだ。しかし、複数の当事者や、アービトラージなど、攻撃や救済に関係のない他のトランザクション送信者による激しい競争が存在するため、Flashbot が常に有効であるとは限らないことがわかりました。この場合、攻撃取引所が設定した（他の攻撃およびレスキュー取引と比較して）最も高い Flashbot 料金であっても、Flashbot 競争に勝つ保証はありません。

もう 1 つの可能なアプローチは、mempool を介して通常のトランザクションを送信することです。トランザクションが適切な場所に配置されていれば、目的を達成することも可能です。ここでの適切な場所とは、攻撃/レスキュー トランザクションが転送トランザクションの後に位置し、転送トランザクションに非常に近いことを意味します (転送トランザクションの次の位置にある場合、理想的には近いほど良いです)。実際、攻撃者 0x48e9** はこの戦略を使用して、Flashbot の料金を支払うことなく 312.014657 ETH を収集することに成功しました。次の 4 つのグラフは、攻撃者による最も収益性の高い 2 つの攻撃を示しています。

• 図 10 と図 11 はそれぞれ、ブロック高さ 14051020 で、被害者 0x3acb** の転送トランザクション (50 ETH の転送) が 65 に位置し、攻撃トランザクション (利益 50 ETH) が 66 に位置していることを示しています。

• 図 12 と図 13 はそれぞれ、ブロック高さ 14052155 で、被害者 0xbea9** の転送トランザクション (200 ETH の転送) が 161 に位置し、攻撃トランザクション (利益 200 ETH) が 164 に位置していることを示しています。

最初のレベルのタイトル

副題

0x4.1 ホワイトハットと攻撃者を区別するにはどうすればよいですか?

ホワイトハットとその行動を特定することは、思っているほど簡単ではないかもしれません。たとえば、アカウント アドレス 0xfa27 は、Etherscan.io によってホワイト ハット、Multichain Exploiter 4 (Whitehat) としてフラグが付けられました。ただし、当初、このアドレスには攻撃者としてフラグが立てられていました: Multichain Exploiter 4。ここでの変更は、プロジェクト当事者と攻撃者の間のやり取りから生じたもので、数回の交渉の後、攻撃者は 50 ETH の利益を報酬として保持し、その他の利益 (Flashbots 手数料などを差し引いたもの) を返すことに同意しました。

• トランザクション 0x3c3d** では、プロジェクト関係者が攻撃者に連絡しました。

• トランザクション 0xd360** で、攻撃者は次のように応答します。

• トランザクション 0x354f** では、プロジェクト当事者は返還された資金を受け取った後、感謝の意を表明しました。

副題

0x4.2 ホワイトハット間の競争

副題

0x4.3 救助活動をより効果的に実行するにはどうすればよいですか?

一方で、透明性の観点から、ホワイトハットは機密情報を漏らすことなく自らの行動をコミュニティに公表することができ、コミュニティの信頼を得るこの方法は実際にうまく機能します。特定の攻撃を阻止するミッションと比較すると、このような救出活動は通常、ホワイトハットと攻撃者が一定期間にわたって複数回交戦する綱引きとなるため、アナウンスを行う時間は十分にあります。もちろん、不必要な害を及ぼさないように、運用の開始時に脆弱性の詳細を公開する必要はありません（ただし、アクションの意図を記録したファイル ハッシュは、私たちが行っているものと同様に、コミュニティと共有できます）この救助では行いました) ; 作戦終了後、この情報はコミュニティに完全に開示されるべきです。

一方、コミュニティ内のすべての部隊が協力して、救助活動をより迅速かつ効果的に行うことができます。これには以下が含まれますが、これに限定されません。

• Flashbot/Miners は、認証された信頼できるホワイト ハットにグリーン チャネルを提供します。これは、攻撃トランザクションを急いでホワイト ハット間の競争を回避するために使用できます。

• Flashbot の料金は、攻撃を受けたプロジェクト当事者が負担します。

• プロジェクト当事者は、ユーザーにタイムリーに警告するために、より便利で迅速なメカニズムを採用しています。

• プロジェクト当事者は、コードに必要な緊急措置をいくつか採用します。