このブログでは、Poly Networkのハッキングの全プロセスをレビューし、そこから得られた教訓について議論したいと思います。
このブログでは+8タイムゾーンを使用していますが、2021年8月10日にPoly Networkがハッキングされていたことは知っていました。しかし、ハッキングがどのように行われたのか、またハッキングの根本原因は何なのか、手がかりはありませんでした。セキュリティリサーチチームとして、私たちは調査を開始しました。
ステップ1：攻撃トランザクションの発見
トランザクション仮想化システム（https://tx.blocksecteam.com）で、攻撃トランザクション0xd8c1f7424593ddba11a0e072b61082bf3d931583cb75f7843fc2a8685d20033aをリプレイしました。
トレースは非常にシンプルで、価格操作を行う他の攻撃とは異なっていました。それらは通常、非常に複雑な関数呼び出しを伴います（Popsicleハックを参照）。
ステップ2：コントラクトコードの分析
攻撃トレースを取得した後、コントラクトのソースコードをレビューする必要がありました。驚くべきことに、Poly NetworkはEtherscanで検証済みのソースコードを公開していませんでした。しかし、githubで公開されているソースコードを見つけることができました。
ソースコードをレビューした結果、明らかなコードの脆弱性はありませんでした。また、攻撃トレースと正規のトランザクショントレースを比較しましたが、類似していることがわかりました。
ステップ3：重要な状態の復旧
次に、攻撃中の重要な状態を復旧しました。攻撃はVerifyHeaderAndExecuteTxEventの呼び出しから開始されたため、いくつかの重要な変数の値を復旧しました（最初の分析で共有しました）[1]。
このプロセス中に、キーパーが1つしか存在しないことを発見しました（上の図を参照）。値は攻撃トレースから取得され、攻撃トランザクションはすべての署名検証を通過したため、潜在的な原因は秘密鍵の漏洩またはサーバーの署名プロセスにおけるバグであると考えました[1]。
しかし、ここで間違いを犯しました。攻撃の分析は、玉ねぎを剥くようなものです。本当の「根本根本根本」原因を特定するまで、一度に一层ずつ剥いていきます。その時、キーパーが変更されたかどうかをさらに確認しませんでした。
ステップ4：新たな手がかり
数時間後、Kelvinとslow mistがTwitterで新たな手がかりを提供し、キーパーが変更されたことを示しました。変更プロセスは、ハッシュの衝突を悪用して強力な関数—「スマート」ハック—を呼び出しました。
これで、最初の分析が不完全であることがわかりました。最新の情報に基づき、キーパーを変更したトランザクションをリプレイしました。やはりトレースは非常にシンプルでした。
しかし、このトランザクション中には、4つのキーパー（1つではなく）が存在することを覚えておいてください。これらのキーはすべて、他の正規のトランザクションと同じものです—つまり、キーは正規のものです。ここで疑問が生じます：なぜキーパーを変更するトランザクションがブロックチェーンに記録され、実行されることができたのでしょうか？
ステップ5：ソーストランザクションの特定
Poly Networkはクロスチェーンブリッジであるため、ソーストランザクションを特定しようとしました。どこかにソーストランザクションが存在するはずです。これを、重要な変数をデコードすることによって行いました（次の図に示す）。これにより、ソースチェーンとPolyチェーンのトランザクションハッシュが表示されました。
公式の値とは異なる表現を持つ tx hash 値のトリックがあります。例えば、図のPolyチェーンのtx hashは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
