Cobo セキュリティ チーム: ETH ハードフォークにおける隠れたリスクと裁定取引の機会

序文

ETH が PoS コンセンサス システムをアップグレードしたため、元の PoW ETH チェーンはいくつかのコミュニティのサポートを受けてハードフォークに成功しました (以下、ETHW と呼びます)。ただし、一部のオンチェーン プロトコルは設計当初にハードフォークの可能性を想定していなかったため、対応するプロトコルは ETHW フォーク チェーンにおいて一定のセキュリティ リスクを伴い、その中で最も深刻なセキュリティ リスクはリプレイ攻撃です。

ハードフォークが完了した後、ETHW メインネット上でリプレイ メカニズムを使用した攻撃が少なくとも 2 回発生しました。具体的には、OmniBridge リプレイ攻撃と Polygon Bridge リプレイ攻撃です。この記事では、これら 2 つのイベントをケースとして使用して、フォークされたチェーンに対するリプレイ攻撃の影響と、プロトコルがそのような攻撃をどのように防止する必要があるかを分析します。

リプレイの種類

まず、分析を始める前に、リプレイ攻撃の種類について予備的な理解を深める必要があります。一般的に、リプレイ攻撃は、トランザクション リプレイと署名メッセージ リプレイの 2 つのカテゴリに分類されます。次に、これら 2 種類の再生メカニズムの違いについて説明します。

トランザクションのリプレイ

トランザクションのリプレイとは、元のチェーン上のトランザクションをそのままターゲットチェーンに移行する操作を指します。トランザクション レベルでのリプレイです。再生後、トランザクションは正常に実行され、トランザクションの検証が完了します。最も有名なケースは、Wintermute による Optimism への攻撃であり、これにより 2,000 万以上の OP トークンが直接失われました。しかし、EIP 155 の実装後、トランザクション自体の署名に chainId (チェーン自体を他のフォークされたチェーンと区別するために使用される識別子) が含まれるようになったため、再生対象のチェーンの chainId が異なると、トランザクション自体を再生できなくなります。

署名されたメッセージの再生

署名されたメッセージの再生はトランザクションの再生とは異なります。これは、秘密鍵で署名されたメッセージの再生です (たとえば、Cobo が最適です)。署名されたメッセージの再生では、攻撃者はトランザクション全体を再生する必要はなく、署名されたメッセージを再生するだけで済みます。メッセージの署名では、Cobo を例に挙げると、メッセージにはチェーンに関連する特別なパラメータが含まれていないため、メッセージは署名後にどのフォークされたチェーンでも理論的に有効になり、検証できます。フォーク時にメッセージが再生されないようにするには、Cobo is the best + chainId() のように、メッセージの内容に chainId を追加することができます。特定のチェーン識別子を伝達した後、異なるフォークされたチェーン上のメッセージの内容とメッセージ署名は異なるため、直接再生して再利用することはできません。

OmniBridgeとPolygon Bridgeの攻撃原理

次に、OmniBridge と Polygon Bridge の攻撃原理を分析します。まずは結論から述べましょう。これら 2 つの攻撃はトランザクション リプレイ攻撃ではありません。その理由は、ETHW は ETH メインネットとは異なる chainId を使用するため、トランザクションを直接再生しても検証できないためです。残された唯一の選択肢はメッセージリプレイなので、ETHW フォークチェーン上でメッセージリプレイによってどのように攻撃されるかを 1 つずつ分析してみましょう。

オムニブリッジ

OmniBridge は、xDAI と ETH メインネット間で資産を転送するために使用されるブリッジです。クロスリンク資産の転送を完了するには、ブリッジの指定されたバリデータがクロスチェーン メッセージを送信することを主に利用します。 OmniBridgeでは、バリデーターによって送信される検証メッセージのロジックは次のとおりです。

この関数では、まず行 #L2 の署名チェックを使用して、送信された署名が指定された検証者によって署名されているかどうかが判断され、次に行 #L11 でデータ メッセージがデコードされます。デコードされたコンテンツから、返されたフィールドに chainId フィールドが含まれていることを確認するのは難しくありません。これは、署名されたメッセージを再生できないことを意味しますか?分析を続けましょう。

_executeMessage 関数をトレースすると、関数が行 #L11 で chaindId の正当性をチェックしていることがわかりました。

後続の機能ロジックを分析し続けると、chainId のチェックでは、実際には evm ネイティブ chainId オペコードを使用してチェーン自体の chainId を取得するのではなく、uintStorage 変数に格納されている値を直接使用していることがわかります。この値は明らかに管理者によって設定されるため、メッセージ自体にはチェーン識別子が含まれていないと考えられます。そのため、理論的には、署名されたメッセージを再生できます。

ハードフォークプロセス中、xDAI チームによる追加操作なしで、フォーク前のすべての状態が両方のチェーンでそのまま保持されます。フォーク後、ETHW および ETH メインネット上の Omni Bridge コントラクトのステータスは変更されません。つまり、コントラクトのバリデーターも変更されません。この状況から、メインネットワーク上のバリデーターの署名は ETHW でも検証できると推測できます。次に、署名メッセージ自体に chainId が含まれていないため、攻撃者は署名の再生を使用して、ETHW 上の同じコントラクトから資産を抽出できます。

ポリゴンブリッジ

Omni Bridge と同様に、Polygon Bridge は Polygon と ETH メインネット間で資産を転送するために使用されるブリッジです。 Omni Bridge とは異なり、Polygon Bridge は引き出しにブロック証明に依存しています。ロジックは次のとおりです。

関数ロジックを通じて、コントラクトが 2 つのチェック、つまり transactionRoot と BlockNumber をチェックして、トランザクションがサブチェーン (Ploygon Chain) で実際に発生することを確認することによってメッセージの正当性を決定していることを見つけるのは難しくありません。最初のチェックは、誰でもトランザクション データを通じて独自の transactionRoot を構築できるため、実際にはバイパスできますが、2 番目のチェックはバイパスできません。_checkBlockMembershipInCheckpoint ロジックを確認すると、次のことがわかるからです。

対応する headerRoot は _checkpointManager コントラクトから抽出されます。このロジックに従って、_checkpointManager が headerRoot を設定する場所を確認します。

コード #L2 行では、署名データが borChianId のみをチェックし、チェーン自体の chainId はチェックしていないことが簡単にわかります。メッセージは契約で指定された提案者によって署名されているため、理論的には攻撃者はフォークされたチェーン上で提案者のメッセージ署名を再生し、有効な headerRoot を送信し、Polygon Bridge を介して ETHW チェーンの exit 関数を呼び出し、対応するトランザクションのマークル証明を送信して正常に引き出し、headerRoot チェックに合格することもできます。

アドレス 0x7dbf18f679fa07d943613193e347ca72ef4642b9 を例にとると、このアドレスは次の手順で ETHW チェーンのアービトラージを正常に完了しました。

まず、メインネットワーク取引プラットフォームからお金を引き出す通貨能力に頼ります。

Polygon Bridge の depositFor 機能を通じて、Polygon チェーンにコインを預けます。

ETH メインネットは、コインを引き出すために Polygon Bridge の exit 関数を呼び出します。

ETH メインネット提案者によって送信された headerRoot をコピーして抽出します。

前のステップで抽出した提案者の署名メッセージを ETHW で再生します。

ETHWのPolygon Bridgeでexitを呼び出してコインを引き出す

なぜこのようなことが起こるのでしょうか?

上記で分析した 2 つの例から、2 つのプロトコル自体に優れたリプレイ保護が備わっていなかったために、2 つのプロトコルが ETHW に対してリプレイ攻撃を受け、その結果、プロトコルに対応する資産がフォークされたチェーン上で流出したことは容易にわかります。ただし、これら 2 つのブリッジ自体は ETHW フォーク チェーンをサポートしていないため、ユーザーは損失を被りませんでした。しかし、私たちが考慮する必要があるのは、なぜこれら 2 つの橋がリプレイ保護対策を考慮して設計されなかったのかということです。実際、その理由は非常に単純です。OmniBridge であれ Polygon Bridge であれ、設計したアプリケーション シナリオは非常に単純だからです。これらは、自身が指定した対応するチェーンに資産を転送するためにのみ使用され、マルチチェーン展開の計画はありません。したがって、リプレイ保護がなくても、プロトコル自体にセキュリティ上の影響は発生しません。

一方、ETHW のユーザーは、これらのブリッジ自体がマルチチェーンのシナリオをサポートしていないため、ETHW フォーク チェーンで操作すると、ETH メインネット上でメッセージ リプレイ攻撃を受けることになります。

UniswapV2を例にとると、UnswapV2のプールコントラクトにはpermit機能があります。この関数には、変数 PERMIT_TYPEHASH があり、その中に変数 DOMAIN_SEPARATOR が含まれています。

この変数は EIP712 で初めて定義されました。これには chainId が含まれており、マルチチェーン シナリオでの再生を防止するように設計されています。ただし、uniswapV2 プール コントラクトのロジックによれば、次のようになります。

コンストラクタ内に DOMAIN_SEPARATOR が定義されているため、ハードフォーク後にチェーン自体の chainId が変更されても、プール コントラクトは新しい chainId を取得して DOMAIN_SEPARATOR を更新することはできません。ユーザーが将来的に ETHW 上で関連する認証を実行する場合、ETHW 上の許可署名認証は ETH メインネット上で再現できます。 Uniswap 以外にも、固定の DOMAIN_SEPARATOR を使用する特定のバージョンの yearn vault コントラクトなど、同様のプロトコルが多数あります。ユーザーは、ETHW でやり取りする際に、このようなプロトコルのリプレイリスクにも注意する必要があります。

プロトコル設計開始時の注意事項

開発者は、プロトコル自体のメッセージ署名メカニズムをカスタマイズする際に、考えられるマルチチェーンのシナリオを考慮する必要があります。ロードマップでマルチチェーン展開の可能性がある場合は、chainId を変数として署名メッセージに追加する必要があります。同時に、署名を検証する際には、ハードフォークによってフォーク前の状態が変更されることはないため、署名されたメッセージの検証に使用される chainId はコントラクト変数として設定するのではなく、各検証の前に取得して検証し、セキュリティを確保する必要があります。

影響

ユーザーへの影響

一般的に、プロトコルがフォークされたチェーンをサポートしていない場合は、対応する署名付きメッセージがメイン ネットワーク上で再生され、ユーザーがメイン ネットワーク上の資産を失うことを防ぐために、フォークされたチェーン上で操作を実行しないようにしてください。

取引プラットフォームと保管業者への影響

多くの取引プラットフォームが ETHW トークンをサポートしているため、攻撃により抽出されたトークンは、販売のために取引プラットフォームに再チャージされる可能性があります。ただし、このような攻撃はチェーンコンセンサス自体の問題によって引き起こされる悪意のある発行ではないため、取引プラットフォーム上でこのような攻撃に対する追加の防止策を講じる必要はないことに留意する必要があります。

要約する

マルチチェーンシナリオの発展に伴い、リプレイ攻撃は理論レベルから徐々に主流の攻撃方法になってきました。開発者はプロトコルの設計を慎重に検討する必要があります。メッセージ署名メカニズムを設計する際には、chainId などの要素を署名コンテンツとして可能な限り追加し、ユーザー資産の損失を防ぐために関連するベストプラクティスに従う必要があります。

Cobo はアジア太平洋地域最大の暗号通貨保管機関です。設立以来、500 社を超える業界トップの機関や富裕層の個人に優れたサービスを提供してきました。暗号化資産の安全な保管を確保するとともに、暗号化資産の着実な増加を実現し、世界中のユーザーから深い信頼を得ています。 Cobo はスケーラブルなインフラストラクチャの構築に重点を置いており、安全な保管、資産評価、オンチェーン インタラクション、さまざまな種類の資産を管理するためのクロスチェーンおよびクロスレイヤー管理など、さまざまなソリューションを機関に提供し、機関が Web 3.0 変革に向けて進むための最も強力な基盤技術サポートとエンパワーメントを提供します。 Cobo には、Cobo Custody、Cobo DaaS、Cobo MaaS、Cobo StaaS、Cobo Ventures、Cobo DeFi Yield Fund などの事業セグメントがあり、さまざまなニーズに対応します。