このブログでは、Poly Networkのハッキングの全プロセスをレビューし、そこから得られた教訓について議論します。
このブログでは、Poly Networkが2021年8月10日（このブログでは+8タイムゾーンを使用）にハッキングされていたことを認識していました。しかし、ハッキングがどのように行われたのか、またハッキングの根本原因については全くの手がかりがありませんでした。セキュリティリサーチチームとして、私たちは調査を開始しました。
ステップ1：攻撃トランザクションの特定
私たちは、トランザクション仮想化システム（https://tx.blocksecteam.com）で、攻撃トランザクション 0xd8c1f7424593ddba11a0e072b61082bf3d931583cb75f7843fc2a8685d20033a をリプレイしました。
トレースは非常にシンプルで、価格操作を行う他の攻撃とは異なりました。それらは通常、非常に複雑な関数呼び出しを伴います（Popsicleハックを参照）。
ステップ2：コントラクトコードの分析
攻撃トレースを取得した後、コントラクトのソースコードを確認する必要があります。驚くべきことに、Poly NetworkはEtherscanで検証済みのソースコードを公開していませんでした。しかし、私たちはGitHubで公開されているソースコードを見つけることができました。
ソースコードをレビューしましたが、明確なコードの脆弱性は見つかりませんでした。また、攻撃トレースと正当なトランザクションのトレースを比較しましたが、それらは類似していました。
ステップ3：重要な状態の復元
次に、攻撃中の重要な状態を復元しました。攻撃はVerifyHeaderAndExecuteTxEventの呼び出しから開始されたため、いくつかの重要な変数の値を復元しました。これは私たちの最初の分析で共有しました[1]。
このプロセス中に、キーパーが1つしか存在しないことを発見しました（上記の図を参照）。値は攻撃トレースから取得され、攻撃トランザクションはすべての署名検証を通過していたため、秘密鍵の漏洩またはサーバーの署名プロセスにおけるバグが潜在的な理由であると考えました[1]。
しかし、ここで間違いを犯しました。攻撃の分析は玉ねぎを剥くようなものです。1枚ずつ剥がしていき、真の「根本的な根本的な」原因を特定します。その時、キーパーが変更されたかどうかをさらに確認しませんでした！
ステップ4：新しい手がかり
数時間後、Kelvinとslow mistがTwitterで新しい手がかりを提供し、キーパーが変更されたことを示しました。変更プロセスは、ハッシュの衝突を悪用して強力な関数、つまり「スマート」ハックを呼び出しました。
ここで、最初の分析が完全ではなかったことに気づきました。最新の情報に基づき、キーパーを変更したトランザクションをリプレイしました。それでもトレースは非常にシンプルでした。
しかし、このトランザクション中には、4つのキーパー（1つではなく）が存在することを覚えておいてください。これらのキーはすべて、他の正当なトランザクションと同じです。つまり、キーは正当です。ここで疑問が生じます。キーパーを変更するトランザクションがチェーンに記録され、実行されたのはなぜでしょうか？
ステップ5：ソーストランザクションの特定
Poly Networkはクロスチェーンブリッジであるため、ソーストランザクションを特定しようとしました。どこかにソーストランザクションが存在するはずです。これは、重要な変数をデコードすることによって行いました（以下の図に示す）。ソースチェーンとPolyチェーンのトランザクションハッシュが表示されます。
どこにも言及されていないトリックがあります。変数内のtxハッシュ値は、Polyチェーンの公式値とは異なる表現になっています。例えば、図中のPolyチェーンのtxハッシュは0x80cc978479eb082e1e656993c63dee7a5d08a00dc2b2aab88bc0e465cfa0721aです。しかし、Polyチェーンブラウザでは、ハッシュ値は1a72a0cf65e4c08bb8aab2c20da0085d7aee3dc69369651e2e08eb798497cc80です（違いがわかりますか？）。私たちは、8月11日16:55にEthereumSecurity tgグループで発見を共有しました。
ステップ6：根本原因の特定
しかし、それでも「キーパーを変更するトランザクション」がチェーンにパッケージ化された理由を説明することはできませんでした。この質問に答えるために、Ontologyチェーンから開始し、トランザクションフローを見つけました。
Ontologyトランザクション -> Ontologyリレイヤー -> Polyチェーン -> Ethereumリレイヤー -> Ethereum
その後、Ontologyチェーンとリレイヤーのソースコードを読みました。数時間後、Ontologyリレイヤーはクロスチェーントランザクションに対して十分な検証を行っていないことがわかりました。これにより、悪意のあるトランザクションがPolyチェーンにパッケージ化される可能性があります。その後、システムは乗っ取られました。
内部で議論し、異議を唱えた後、8月12日02:41にTwitterとmedium[3]で発見を発表しました。
教訓
-
設計によるセキュリティ。 セキュリティはDeFiプロジェクトの全プロセスにおいて考慮されるべきです。ユーザーはプロジェクトにお金を託します。したがって、プロジェクトはその信頼に値するべきです。残念ながら、Poly Networkのセキュリティに対する無関心が見られました。例えば、検証の欠如は旧式のセキュリティ脆弱性であり、私は学部生向けのクラスで教えました。
-
6億ドル以上のTVLを持つDeFiプロジェクトなどに検証済みのソースコードがない。 分散型インフラストラクチャの基盤は信頼であり、信頼の基盤は透明性です。残念ながら、ユーザーはブラックボックスプロジェクトにお金を投じることを厭いません。これは私を驚かせ、懸念させています。ユーザーのセキュリティ意識をどのように向上させるかは、新しいソリューションが必要かもしれません。
参考文献
[1]https://blocksecteam.medium.com/the-initial-analysis-of-the-polynetwork-hack-270ac6072e2a
[2]https://twitter.com/kelvinfichter/status/1425290462076747777
[3]https://blocksecteam.medium.com/the-further-analysis-of-the-poly-network-attack-6c459199c057
クレジット：Yufeng Hu, Siwei Wu, Lei Wu, Yajin Zhou @ BlockSecTeam
