Poly Network攻撃の主要ステップの詳細な分析

序文 2021年8月10日北京時間、クロスチェーンブリッジプロジェクトPoly Networkが攻撃を受け、損失は6億ドルを超えました。攻撃者は後に盗んだデジタル通貨を返済しましたが、これは依然としてブロックチェーン史上最大の攻撃です。攻撃プロセス全体にはさまざまなブロックチェーン プラットフォームが関与し、契約とリレーラー間の複雑な相互作用があるため、既存の分析レポートでは、攻撃の完全なプロセスと脆弱性の根本原因を明確に整理できていません。
攻撃全体は、キーパー署名の変更と最終的なコインの引き出しを含む 2 つの主な段階に分かれています。第 2 段階では、キーパー署名が変更されているため、攻撃者は悪意のある引き出しトランザクションを直接構築できます。詳細については前回のレポートをご参照ください。しかし、キーパー署名を変更するトランザクションが最終的にターゲットチェーン上でどのように実行されるかを説明する詳細な記事は現在ありません。このステップは攻撃の最も中核となるステップです。
このレポートは、キーパー署名トランザクション (オントロジー チェーン上のトランザクション 0xf771ba610625d5a37b67d30bf2f8829703540c86ad76542802567caaffff280c) を変更することから始まり、脆弱性の根本的な原理と性質を分析します。 Keeper が変更される理由として、次のことが考えられます。
ソースチェーン（オントロジー）上のリレーヤーは、チェーン上のトランザクションの意味検証を行わないため、キーパーの変更を含む悪意のあるトランザクションがポリチェーンにパッケージ化される可能性があります。
ターゲットチェーン（Ethereum）上のリレーヤーがトランザクションを検証しますが、攻撃者はEthereum上のEthCrossChainManagerコントラクトを直接呼び出し、最終的にEthCrossChainDataコントラクトを呼び出して署名の変更を完了することができます。
攻撃者はハッシュの競合を引き起こす可能性のある関数の署名を慎重に入手し、putCurEpochConPubKeyBytesを呼び出して署名を変更した[2]
トランザクションと契約に関連する相互作用プロセスは次のとおりです。
オントロジートランザクション -> オントロジーリレー -> ポリチェーン -> イーサリアムリレー -> イーサリアム
イーサリアム
0x838bf9e95cb12dd76a54c9f9d2e3082eaf928270: Ethクロスチェーンマネージャー
0xcf2afe102057ba5c16f899271045a0a37fcb10f2: クロスチェーンデータ
0x250e76987d838a75310c34bf422ea9f1ac4cc906: ロックプロキシ
0xb1f70464bd95b774c6ce60fc706eb5f9e35cb5f06e6cfe7c17dcda46ffd59581: キーパーのトランザクションを変更する
オントロジー
0xf771ba610625d5a37b67d30bf2f8829703540c86ad76542802567caaffff280c: キーパーのトランザクションを変更する
ポリ
0x1a72a0cf65e4c08bb8aab2c20da0085d7aee3dc69369651e2e08eb798497cc80: キーパーのトランザクション攻撃プロセスを変更します。攻撃全体は、大まかに3つのステップに分けられます。最初のステップは、オントロジー チェーン上で悪意のあるトランザクション (0xf771ba610625d5a37b67d30bf2f8829703540c86ad76542802567caaffff280c) を生成することです。 2 番目のステップは、Ethereum EthCrossChainData 契約のキーパー署名を変更することです。 3 番目のステップは、最終的な攻撃を開始してコインを引き出すための悪意のあるトランザクションを構築することです。
ステップ 1 攻撃者はまず、Ontology (0xf771ba610625d5a37b67d30bf2f8829703540c86ad76542802567caaffff280c) でクロスチェーン トランザクションを開始しました。これには攻撃ペイロードが含まれていました。

トランザクションには、ハッシュ衝突を引き起こして putCurEpochConPubKeyBytes 関数 (Ethereum 上の EthCrossChainData コントラクトに属する) を呼び出すことを目的とした、慎重に設計された関数名 (図の 6631 で始まる番号、変換後は f1121318093) が含まれていることがわかります。ハッシュ関数の衝突の詳細についてはインターネット上で多くの議論が行われているので、[2]を参照してください。
その後、トランザクションはオントロジー リレーヤーによって受信されます。ここでは厳密な検証は行われないことに注意してください。トランザクションは、Relayer (0x1a72a0cf65e4c08bb8aab2c20da0085d7aee3dc69369651e2e08eb798497cc80) を介して Poly Chain に正常にアップロードされます。 Ethereum Relayer は新しいブロックの生成を感知します。
しかし、トランザクションは Ethereum Relayer によって拒否されました。その理由は、Ethereum Relayer がターゲット コントラクト アドレスをチェックし、ターゲット アドレスとして LockProxy コントラクトのみを許可する一方で、攻撃者が EthCrossChainData アドレスを渡したためです。
したがって、攻撃者の攻撃経路はここで中断されます。しかし、前述したように、悪意のあるペイロードを含む攻撃トランザクションは Poly Chain に正常にアップロードされており、さらに悪用される可能性があります。
ステップ 2 では、攻撃者は EthCrossChainManager コントラクトの verifyHeaderAndExecuteTx 関数を呼び出して、前のステップで Ploy Chain ブロックに保存された攻撃トランザクション データを入力として使用し、手動でトランザクションを開始します。このブロックはポリチェーン上の正当なブロックであるため、verifyHeaderAndExecuteTx での署名とマークル証明の検証に合格できます。次に、EthCrossChainData コントラクトの putCurEpochConPubKeyBytes 関数を実行して、元の 4 つのキーパーを指定されたアドレス (0xA87fB85A93Ca072Cd4e5F0D4f178Bc831Df8a00B) に変更します。
ステップ 3: キーパーが変更された後、攻撃者はターゲット チェーンで verifyHeaderAndExecuteTx 関数を直接呼び出します (ポリ チェーンを経由せずに - キーパーが変更されているため、攻撃者はターゲット チェーンにとって妥当と思われるポリ チェーン上のブロックに任意に署名できます)。最後に Unlock 関数 (LockProxy 契約に属する) を呼び出して、多額の資金を転送し、プロジェクト パーティに重大な損失をもたらします。攻撃の詳細については前回のレポート[1]を参照してください。
リレー コードの分析 この攻撃の間、Ontology と Ethereum の両方に、Ontology からのトランザクションをポリ チェーンに配置し、Ethereum のポリ チェーンにトランザクションを配置する役割を担うリレー システムが存在します。これら 2 つの Relayer は、Go 言語で実装されたサービス プロセスです。
しかし、どちらのリレーでも効果的な検証が欠けていることがわかりました。これは
攻撃者は、オントロジー上で悪意のあるクロスチェーントランザクションを構築し、それをポリチェーンにパッケージ化することができます。
Ethereum の Relayer には検証機能がありますが、攻撃者は Ethereum 上のオンチェーン コントラクトと直接やり取りし、悪意のある機能を直接実行できます。
オントロジーリレーヤーはオントロジー上のクロスチェーントランザクションを完全に信頼します
Poly Network の ont_relayer (https://github.com/polynetwork/ont-relayer) は、Ontology チェーン上のクロスチェーン トランザクションを監視し、それらを Poly Chain にパッケージ化する役割を担っています。
注記：
Ontology Relayer では、Side は Ontology Chain を指します。アライアンスはポリチェーンを指します。
CrossChainContractAddress は、Ontology チェーン上の元の番号 09 を持つスマート コントラクトです。

上図では、Ontology Relayer が起動すると、Ontology Chain と Poly Chain 間のクロスチェーントランザクションを監視し、Poly Chain 上のクロスチェーントランザクションのステータスを確認するために 3 つの Goroutine が開始されます。このレポートでは、69 行目の Side を監視するコード ロジックのみに焦点を当てます。

上の図では、Ontology Relayer は Ontology チェーンによって提供される RPC インターフェイス (215 行目、SDK 関数 GetSmartContractEventByBlock を呼び出す) を呼び出して、ブロック内でトリガーされたスマート コントラクト イベントを取得します。 228 行目と 232 行目は、Ontology Relayer が Ontology Chain 上の CrossChainContractAddress によってトリガーされる makeFromOntProof イベントのみをリッスンすることを示しています。

上図では、オントロジー チェーン上でクロスチェーン トランザクションを処理する際に、オントロジー リレーヤーは、オントロジー チェーンに送信された 2 つの RPC 要求チェック (チェック 1 とチェック 4) と、パラメータが空かどうかを確認する 3 つのチェック (チェック 2、チェック 3、チェック 5) を含む合計 5 つのチェックを実行します。これら 5 つのチェックはすべて通常のチェックであり、オントロジー チェーンからのクロスチェーン トランザクションに対してはセマンティック検証は実行されません。 167 行目と 171 行目では、ターゲット チェーンでの実行に必要なトランザクション パラメータ情報 (proof、auditPath) を抽出します。 183 行目はトランザクションをポリチェーンに送信します。

ポリチェーン上でトランザクションを構築した後、オントロジーリレーヤーはポリチェーンにトランザクションを送信するための RPC 要求を開始します (行 164、関数呼び出し SendTransaction)。

ProcessToAliianceCheckAndRetry という名前のこの Goroutine は、失敗したトランザクションを再送信するだけで、オントロジー チェーンからのクロスチェーン トランザクションに対するセマンティック検証は実行しません。
これまでのところ、ont-relayer は Ontology Chain からの CrossChainContractAddress によってトリガーされたすべての makeFromOntProof イベントをリッスンし、セマンティック検証なしでトランザクションを Poly Chain に転送していることがわかります。誰かが Ontology に送信したクロスチェーン トランザクションはすべて、CrossChainContractAddress の makeFromOntProof イベントをトリガーするため、Ontology Relayer はすべてのクロスチェーン トランザクションを Ontology から Poly チェーンに転送します。
Ethereum Relayer での無効な検証
Ethereum Relayer は、ポリチェーンを監視し、ターゲットチェーンが Ethereum であるクロスチェーントランザクションを Ethereum に転送する役割を担います。

Ethereum Relayer は、ポリチェーンを監視するために Goroutine を開始します。

Ethereum Relayer は、ターゲット チェーンが Ethereum である Poly Chain 上のすべてのクロスチェーン トランザクションを監視します (275 行目から 278 行目)。 Ethereum Relayer は、クロスチェーン トランザクションのターゲット コントラクトが config.TargetContracts で指定されたコントラクトの 1 つであるかどうかを確認します。そうでない場合、クロスチェーントランザクションは Ethereum に送信されません (行 315)。
Ethereum Relayer は、Poly Chain 上のクロスチェーントランザクションを、対象コントラクトの制限など部分的に検証していますが、Poly Chain とは異なり、誰でも Ethereum 上の EthCrossChainManager コントラクトにトランザクションを送信できます。つまり、ここで Ethereum Relayer によって行われる検証には実質的な意味はありません。悪意のあるペイロードを含むクロスチェーントランザクションがポリチェーンに正常にパッケージ化されていれば（リレーによってイーサリアムチェーンに転送されてはいないものの）、誰でもパッケージ化されたブロックデータを直接使用してペイロードをイーサリアムのEthCrossChainManagerコントラクトに送信し、実行することができます（このプロセスでは、チェーンに正常にアップロードされたポリチェーンブロックデータであるため、マークル証明を検証できます）。
攻撃者は上記の 2 つの欠陥を利用して、攻撃プロセスのステップ 1 と 2 を完了しました。

結論として、攻撃プロセス全体の徹底的なレビューと詳細な分析を通じて、Relayer の検証が不完全であることが攻撃の根本的な原因であると考えています。その他の側面（ハッシュ競合の悪用など）は、より洗練された攻撃手法です。要約すると、クロスチェーン検証と認証はクロスチェーンシステムのセキュリティの鍵であり、コミュニティの努力に値します。 （BlockSecチーム）