この記事はコミュニティへの寄稿です。著者は CertiK の監査人である Minzhi He 氏です。
この記事で表明されている見解は寄稿者/著者の見解であり、必ずしもバイナンス アカデミーの見解を反映しているわけではありません。
まとめ
ブロックチェーン ブリッジは、ブロックチェーン空間で相互運用性を実現するための基礎です。したがって、クロスチェーンブリッジングテクノロジーのセキュリティは非常に重要です。ブロックチェーン ブリッジの一般的なセキュリティ脆弱性には、オンチェーンおよびオフチェーンの検証が不十分であること、ネイティブ トークンの不適切な処理、構成ミスなどが含まれます。検証ロジックが適切であることを確認するには、考えられるすべての攻撃ベクトルに対してクロスチェーン ブリッジをテストすることをお勧めします。
導入
ブロックチェーン ブリッジは、2 つのブロックチェーンを接続し、相互作用できるようにするプロトコルです。ブロックチェーンブリッジを通じて、ユーザーがイーサリアムネットワーク上のDeFiアクティビティに参加したい場合、ビットコインを保持するだけでよく、目標を達成するためにビットコインを売却する必要はありません。
ブロックチェーン ブリッジは、ブロックチェーン分野における相互運用性の基盤です。これらは機能するためにさまざまなオンチェーンおよびオフチェーン検証を使用するため、さまざまなセキュリティ脆弱性も存在する可能性があります。
ブロックチェーン ブリッジのセキュリティが重要なのはなぜですか?
ブロックチェーン ブリッジは通常、ユーザーがあるチェーンから別のチェーンに転送したいトークンを保持します。ブロックチェーン ブリッジは通常、スマート コントラクトの形式で導入され、クロスチェーン転送が蓄積され続けると、この膨大な数のトークンがハッカーの憧れの的になります。
さらに、ブロックチェーン ブリッジには多くのコンポーネントが関与しているため、攻撃対象領域が大きくなる傾向があります。したがって、犯罪者は多額の資金を獲得するためにクロスチェーン アプリケーションをターゲットにする強い動機を持っています。
CertiK の推計によると、ブロックチェーン ブリッジ攻撃は 2022 年に 13 億ドル以上の損失を引き起こし、同年の損失総額の 36% を占めました。
一般的なクロスチェーンブリッジングのセキュリティ脆弱性
ブロックチェーン ブリッジのセキュリティを強化するには、一般的なクロスチェーン ブリッジのセキュリティ脆弱性を理解し、ブロックチェーン ブリッジを起動する前にテストすることが重要です。これらの脆弱性は主に次の 4 つの側面から発生します。
不十分なオンチェーン検証
単純なブロックチェーン ブリッジ、特に特定の dApp 用に設計されたブリッジの場合、通常は最小限のレベルのオンチェーン検証のみが行われます。これらのブリッジは、集中化されたバックエンドに依存して、ミント、書き込み、トークン転送などの基本操作を実行し、すべての検証はオフチェーンで行われます。
他のタイプのブリッジはスマート コントラクトを使用してメッセージを検証し、オンチェーンで検証します。この場合、ユーザーがチェーンに資金を入金すると、スマート コントラクトは署名付きメッセージを生成し、トランザクションで署名を返します。この署名は入金の証拠として使用され、別のチェーンでのユーザーの出金リクエストを検証するために使用されます。このプロセスにより、リプレイ攻撃や補充記録の改ざんなど、さまざまなセキュリティ攻撃を防ぐことができます。
ただし、オンチェーン検証プロセスに脆弱性がある場合、攻撃により重大な損害が発生する可能性があります。たとえば、ブロックチェーンが取引記録を検証するためにマークル ツリーを使用している場合、攻撃者は偽造された証拠を生成する可能性があります。これは、検証プロセスに脆弱性がある場合、攻撃者が証拠検証をバイパスし、自分のアカウントに新しいトークンを作成できることを意味します。
一部のブロックチェーン ブリッジは、「ラップされたトークン」の概念を実装しています。たとえば、ユーザーが DAI をイーサリアムから BNB チェーンに転送すると、その DAI はイーサリアム契約から取り出され、同量のラップされた DAI が BNB チェーンで発行されます。
ただし、このトランザクションが適切に検証されない場合、攻撃者はこの機能を操作する悪意のあるコントラクトを展開して、ラップされたトークンをブリッジから間違ったアドレスにルーティングする可能性があります。
また、攻撃者は、「TransferFrom」関数を使用してトークンを転送する前に、被害者がクロスチェーン ブリッジ コントラクトを承認する必要があり、それによってクロスチェーン ブリッジ コントラクトから資産が奪われます。
しかし、厄介な点は、多くのクロスチェーン ブリッジでは、dApp ユーザーが無制限の量のトークンを承認する必要があることです。これは非常に一般的であり、ガス料金を削減できますが、スマート コントラクトはユーザーのウォレットから無制限の量のトークンにアクセスできます。それはさらなるリスクをもたらします。攻撃者は、これらの過小検証と過剰承認を悪用して、他のユーザーから自分自身にトークンを転送します。
オフチェーン検証が不十分
一部のクロスチェーン ブリッジ システムでは、オフチェーン バックエンド サーバーが、ブロックチェーンから送信されたメッセージの正当性を検証する上で重要な役割を果たします。この場合、リチャージトランザクションの検証に焦点を当てる必要があります。
オフチェーン検証を備えたブロックチェーン ブリッジは次のように動作します。
ユーザーは dApp を操作し、ソース チェーン上のスマート コントラクトにトークンをデポジットします。
次に、dApp は API 経由でデポジット トランザクション ハッシュをバックエンド サーバーに送信します。
トランザクション ハッシュはサーバーによって複数回検証される必要があります。正当であるとみなされた場合、署名者はメッセージに署名し、その署名を API 経由でユーザー インターフェイスに送り返します。
署名が受信されると、dApp はそれを検証し、ユーザーがターゲット チェーンからトークンを引き出すことを許可します。
バックエンド サーバーは、処理するリチャージ トランザクションが本物であり、偽造されていないことを確認する必要があります。このバックエンド サーバーは、ユーザーがターゲット チェーン上でトークンを引き出すことができるかどうかを決定し、攻撃の最初のターゲットとなります。
バックエンド サーバーは、トランザクション開始イベントの構造と、イベントを開始したコントラクト アドレスを検証する必要があります。後者が無視された場合、攻撃者は悪意のあるコントラクトを展開して、正規のリチャージ イベントと同じ構造を持つリチャージ イベントを偽造する可能性があります。
バックエンド サーバーは、どのアドレスがイベントを開始したかを検証しない場合、それが有効なトランザクションであると想定し、メッセージに署名します。その後、攻撃者はトランザクション ハッシュをバックエンド サーバーに送信し、検証をバイパスしてターゲット チェーンからトークンを引き出すことができます。
不適切なネイティブ トークンの処理
クロスチェーン ブリッジは、ネイティブ トークンとユーティリティ トークンに対して異なるアプローチを採用します。たとえば、イーサリアム ネットワークでは、ネイティブ トークンは ETH であり、ほとんどのユーティリティ トークンは ERC-20 標準に準拠しています。
ユーザーが自分の ETH を別のチェーンに転送する場合は、まずそれをクロスチェーン ブリッジ コントラクトに入金する必要があります。これを行うには、ユーザーはトランザクションに ETH を添付するだけで、「msg.value」トランザクション フィールドを読み取ることで ETH の量を取得できます。
ERC-20 トークンの入金は、ETH の入金とは大きく異なります。 ERC-20 トークンをデポジットするには、ユーザーはまずクロスチェーン ブリッジ コントラクトにトークンの使用を許可する必要があります。承認してトークンをクロスチェーンブリッジコントラクトに預けると、コントラクトは「burnFrom()」関数を使用してユーザーのトークンを破棄するか、「transferFrom()」関数を使用してユーザーのトークンをコントラクトに転送します。
どの操作であるかを区別するには、同じ関数内で if-else ステートメントを使用できます。または、各シナリオを処理する 2 つの別個の関数を作成します。処理方法が異なるため、ユーザーがERC-20入金機能を使用してETHを入金しようとすると、ETHが失われる可能性があります。
ERC-20 デポジットリクエストを処理するとき、ユーザーは通常、デポジット関数への入力パラメータとしてトークンアドレスを提供します。トランザクション中に信頼できない外部呼び出しが発生する可能性があるため、これは重大なリスクをもたらします。ホワイトリストを使用して、クロスチェーン ブリッジでサポートされているトークンのみを含めることは、リスクを最小限に抑えるための一般的な方法です。ホワイトリストに登録されたアドレスのみがパラメータとして渡されます。プロジェクト チームがトークン アドレスをフィルタリングしているため、これにより外部呼び出しが防止されます。
ただし、ネイティブ トークンにはアドレスがないため、クロスチェーン ブリッジがネイティブ トークンのクロスチェーン転送を処理する場合にも問題が発生します。ネイティブ トークンは、特別なアドレス、「ゼロ アドレス」(0x000... 0) で表すことができます。しかし、これには問題があり、ホワイトリスト検証ロジックが正しく実装されていない場合、関数にゼロのアドレスを渡すとホワイトリスト検証がバイパスされる可能性があります。
クロスチェーンブリッジコントラクトが「TransferFrom」を呼び出してユーザー資産をコントラクトに転送すると、「transferFrom」関数がゼロアドレスに実装されていないため、ゼロアドレスへの外部呼び出しは false を返します。ただし、コントラクトが戻り値を正しく処理しない場合、トランザクションは引き続き発生する可能性があります。これにより、攻撃者がトークンをコントラクトに転送せずにトランザクションを実行する機会が生まれます。
構成エラー
ほとんどのブロックチェーン ブリッジには、トークンとアドレスのホワイトリストまたはブラックリストへの登録、署名者の割り当てまたは変更、その他の主要な構成を担当する特権ロールがあります。一見些細な見落としが重大な損害につながる可能性があるため、すべての構成が正確であることを確認することが重要です。
実際、攻撃者が設定ミスにより転送記録の検証を回避する事件が発生しています。プロジェクト チームは、特定の変数が変更されるハッキングの数日前にプロトコルのアップグレードを実施しました。この変数は、信頼できるメッセージを表すために使用されるデフォルト値です。この変更により、すべてのメッセージが自動的に認証されたものとみなされ、攻撃者がランダムなメッセージを送信して検証に合格することが可能になります。
クロスチェーンブリッジのセキュリティを向上させる方法
上記の 4 つの一般的なクロスチェーン ブリッジの脆弱性は、接続されたブロックチェーン エコシステムのセキュリティが直面する課題を過小評価できないことを示しています。これらの脆弱性に対処するには、「地域の状況に応じて」考慮する必要があります。すべての脆弱性に対処する万能の方法はありません。
たとえば、各クロスチェーン ブリッジには固有の検証要件があるため、一般的なガイドラインを提供するだけでは検証プロセスにエラーがないことを保証するのは困難です。検証バイパスを防ぐ最も効果的な方法は、考えられるすべての攻撃ベクトルに対してクロスチェーン ブリッジを徹底的にテストし、検証ロジックが合理的であることを確認することです。
全体として、クロスチェーン ブリッジの最も一般的なセキュリティ脆弱性に特別な注意を払い、潜在的な攻撃に対して厳密なテストを実施する必要があります。
結論
資金が膨大であるため、クロスチェーンブリッジは長い間攻撃者の標的となってきました。構築者は、包括的な導入前テストを実施し、第三者による監査を組み込むことで、クロスチェーン ブリッジのセキュリティを強化できます。これにより、過去数年間にわたってクロスチェーン ブリッジに迫ってきた壊滅的なハッキングのリスクを軽減できます。クロスチェーン ブリッジはマルチチェーンの世界では重要ですが、効果的な Web3 インフラストラクチャを設計および構築する際には、セキュリティを最優先に考慮する必要があります。
参考文献
ブロックチェーンブリッジとは何ですか?
クロスチェーンの相互運用性とは何ですか?
3 つの人気のある暗号通貨ブリッジとその仕組み
ラップされたトークンとは何ですか?
免責事項とリスク警告: この記事の内容は事実であり、一般的な情報および教育のみを目的としており、いかなる表明や保証も構成するものではありません。この記事は、財務上、法律上、またはその他の専門的なアドバイスとして解釈されるべきではなく、特定の製品やサービスの購入を推奨するものでもありません。適切な専門アドバイザーから独自のアドバイスを求める必要があります。この記事が第三者の寄稿者によって提供された場合、この記事で表明された見解は第三者の寄稿者に属し、必ずしもバイナンス アカデミーの見解を反映しているわけではないことに注意してください。詳細については、ここをクリックして免責事項の全文をお読みください。デジタル資産の価格は変動する可能性があります。投資価値は上昇することもあれば下落する可能性があり、投資元本が返還されない可能性があります。あなたは自分自身の投資決定に対して単独で責任を負い、Binance Academyはあなたが被る可能性のある損失に対して責任を負いません。この記事は、財務上、法律上、またはその他の専門的なアドバイスを構成するものではありません。詳細については、利用規約とリスク警告をご覧ください。