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

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チーム)

<<:  EIP-1559 がオンラインになってから 1 週間後、イーサリアムマイナーの収入は増加しましたか、それとも減少しましたか?

>>:  ビットコインETFは申請の急増を歓迎するが、暗号通貨資産の需要は急激に冷え込む

推薦する

BitFury: 投資家はビットコインが市場で「最も安全な」暗号通貨であることに気づき始めている

ビットコインは世界通貨としての地位を確立しつつあります。大手メディアの報道がないにもかかわらず、ビッ...

ビットコインマイナーが失った金額は過去10年間で最低レベルとなっている。これは価格にどのような影響を与えるでしょうか?

マイナーによるビットコインの流出は10年ぶりの低水準に落ち込んでおり、アナリストらはビットコインを溜...

暗号通貨業界に女性が不足している6つの理由

BanklessDAO に入社して間もなく、私は Writers Guild のタレントスカウトにな...

共生か分裂か?レイヤー2とイーサリアムの関係は何ですか?

イーサリアムは最近問題を抱えています。センチメントは低く、批評家たちはETHがSOLよりもパフォーマ...

観察 |デジタル通貨は規制圧力と国際的な認知の中で前進に苦戦している

まとめイベント: 米国 SEC はビットコイン ETF を作成する最新の提案を拒否しました。 Vis...

選挙門の外の野蛮人:仮想通貨クジラが静かに米国政治の舞台を侵食している

7月23日、FECの公式サイトによると、ブロックチェーングループのフェアシェイクは、今回の選挙サイク...

資本の流入が止まったのに、なぜウォール街はグレイスケール・ビットコイン・トラストを放棄し始めたのか?

グレイスケール・ビットコイン・トラスト(GBTC)がビットコインに対する機関投資家の関心を測るベンチ...

暗号通貨の未来が規制当局に左右される理由

暗号通貨業界と投資家からより明確な暗号通貨規制を求める声が高まり、デジタル資産は単一の機関の規則の下...

DTCC CEO、年次株主レターでブロックチェーン技術の統合を進める計画を​​提案

クレイジー解説:米国の主要な預金・決済機関として、DTCCは金融分野におけるブロックチェーン技術と分...

3月のビットコインのオンチェーン取引量は約3663億ドルに達し、過去最高を記録した。

TheBlock Researchが4月20日にまとめたデータによると、ビットコインの月間オンチェ...

『マネーショート 華麗なる大逆転』の著者がビットコインについて語る:米国連邦政府の混乱と間違いなく関係がある

アメリカのベストセラー作家マイケル・ルイス氏は最近、ヤフー・ファイナンスの司会者ジェン・ロジャース氏...

Binance LaunchPad IPO収益

Binance LaunchPadは最近、悪い評価を受けていますが、「どんなに貧しくても、教育は貧し...

複数の犯罪の疑いでFBIが捜査?ジャスティン・サンは否定し、米国に住んでいないと述べた。

告発された後、ジャスティン・サンはソーシャルメディア上で、コンプライアンスを非常に重視しており、コン...

ブロックチェーン業界は物語のジレンマに直面しているのでしょうか、それとも語るべき物語がないのでしょうか?

出典: LongHash編集者注: 原題は「ブロックチェーン技術の物語的ジレンマ: その解決策」です...