この記事はコミュニティ投稿です。著者は CertiK の監査人である Minzhi He です。

この記事の見解は寄稿者/著者のものであり、必ずしも Binance Academy の見解を反映するものではありません。

TL;DR

ブロックチェーン ブリッジは、ブロックチェーン空間での相互運用性を実現する上で不可欠です。したがって、ブリッジのセキュリティは極めて重要です。ブリッジの一般的なセキュリティ脆弱性には、オンチェーンおよびオフチェーンの検証の弱さ、ネイティブ トークンの不適切な処理、構成ミスなどがあります。検証ロジックが適切であることを確認するために、考えられるすべての攻撃ベクトルに対してブリッジをテストすることをお勧めします。

導入

ブロックチェーン ブリッジは、2 つのブロックチェーンを接続して、それらの間のやり取りを可能にするプロトコルです。ビットコインを所有していても、Ethereum ネットワーク上の DeFi アクティビティに参加したい場合は、ブロックチェーン ブリッジを使用すると、ビットコインを売却せずに参加できます。

ブロックチェーン ブリッジは、ブロックチェーン空間内で相互運用性を実現するための基礎となります。さまざまなオンチェーンおよびオフチェーン検証を使用して機能するため、セキュリティ上の脆弱性が異なります。

ブリッジセキュリティが重要な理由

ブリッジは通常、ユーザーがチェーン間で転送したいトークンを保持します。ブリッジはスマート コントラクトとして展開されることが多く、チェーン間の転送が蓄積されるにつれて大量のトークンを保持するため、ハッカーにとって格好のターゲットになります。

さらに、ブロックチェーン ブリッジは多くのコンポーネントが関係するため、攻撃対象領域が広くなります。そのため、悪意のある攻撃者は、クロスチェーン アプリケーションを標的にして多額の資金を流出させようとします。

CertiKの推定によると、橋の攻撃により2022年に13億ドルを超える損失が発生し、その年の総損失の36％を占めました。

一般的なブリッジセキュリティの脆弱性

ブリッジのセキュリティを強化するには、一般的なブリッジのセキュリティ脆弱性を理解し、起動前にブリッジをテストすることが重要です。これらの脆弱性は、次の 4 つの領域に分類できます。

オンチェーン検証が弱い

シンプルなブリッジ、特に特定の DApp 向けに設計されたブリッジでは、オンチェーン検証は最小限に抑えられます。これらのブリッジは、ミント、バーン、トークン転送などの基本的な操作を実行するために集中型のバックエンドに依存し、検証はすべてオフチェーンで実行されます。

対照的に、他のタイプのブリッジは、スマート コントラクトを使用してメッセージを検証し、チェーン上で検証を実行します。このシナリオでは、ユーザーがチェーンに資金を入金すると、スマート コントラクトは署名付きメッセージを生成し、トランザクションで署名を返します。この署名は入金の証明として機能し、他のチェーンでのユーザーの引き出し要求を検証するために使用されます。このプロセスは、リプレイ攻撃や偽造された入金記録など、さまざまなセキュリティ攻撃を防ぐことができるはずです。

ただし、オンチェーン検証プロセス中に脆弱性がある場合、攻撃者は重大な損害を引き起こす可能性があります。たとえば、ブリッジが Merkle ツリーを使用してトランザクション レコードを検証する場合、攻撃者は偽造された証明を生成することができます。つまり、検証プロセスに脆弱性がある場合、攻撃者は証明の検証をバイパスして、自分のアカウントに新しいトークンを発行することができます。

特定のブリッジは、「ラップされたトークン」の概念を実装しています。たとえば、ユーザーが DAI を Ethereum から BNB チェーンに転送すると、その DAI は Ethereum 契約から取得され、同等の量のラップされた DAI が BNB チェーンで発行されます。

ただし、このトランザクションが適切に検証されない場合、攻撃者は関数を操作して、ブリッジから間違ったアドレスにラップされたトークンをルーティングする悪意のあるコントラクトを展開する可能性があります。

また、攻撃者は、ブリッジ コントラクトから資産を流出させるために、「transferFrom」関数を使用してトークンを転送するためのブリッジ コントラクトを被害者が承認する必要もあります。

残念ながら、多くのブリッジが DApp ユーザーから無制限のトークン承認を要求するため、状況はさらに悪化しています。これはガス料金を下げる一般的な方法ですが、スマート コントラクトがユーザーのウォレットから無制限の数のトークンにアクセスできるようにすることで、追加のリスクを生み出します。攻撃者は検証の欠如と過剰な承認を悪用して、他のユーザーから自分にトークンを転送することができます。

弱いオフチェーン検証

一部のブリッジ システムでは、オフチェーン バックエンド サーバーがブロックチェーンから送信されたメッセージの正当性を検証する上で重要な役割を果たします。この例では、入金取引の検証に焦点を当てています。

オフチェーン検証を備えたブロックチェーン ブリッジは次のように機能します。

1. ユーザーは DApp と対話して、ソース チェーン上のスマート コントラクトにトークンを預けます。

2. 次に、DApp は API 経由で入金トランザクション ハッシュをバックエンド サーバーに送信します。

3. トランザクション ハッシュは、サーバーによって複数の検証を受けます。正当であると判断された場合、署名者はメッセージに署名し、API 経由でユーザー インターフェイスに署名を送り返します。

4. DApp は署名を受け取るとそれを検証し、ユーザーがソース チェーンからトークンを引き出すことを許可します。

バックエンド サーバーは、処理する入金トランザクションが実際に発生し、偽造されていないことを確認する必要があります。このバックエンド サーバーは、ユーザーがターゲット チェーンでトークンを引き出せるかどうかを決定するため、攻撃者にとって価値の高いターゲットとなります。

バックエンド サーバーは、トランザクションの発行イベントの構造と、イベントを発行したコントラクト アドレスを検証する必要があります。後者を無視すると、攻撃者は悪意のあるコントラクトを展開して、正当な入金イベントと同じ構造の入金イベントを偽造する可能性があります。

バックエンド サーバーがイベントを発行したアドレスを検証しない場合、これを有効なトランザクションと見なし、メッセージに署名します。その後、攻撃者はトランザクション ハッシュをバックエンドに送信して検証を回避し、ターゲット チェーンからトークンを引き出すことができます。

ネイティブトークンの不適切な取り扱い

ブリッジは、ネイティブ トークンとユーティリティ トークンの処理に対して異なるアプローチを採用しています。たとえば、Ethereum ネットワークでは、ネイティブ トークンは ETH であり、ほとんどのユーティリティ トークンは ERC-20 標準に準拠しています。

ユーザーが ETH を別のチェーンに転送する場合、まずブリッジ コントラクトに ETH を預ける必要があります。これを行うには、ユーザーは ETH をトランザクションに添付するだけで、トランザクションの「msg.value」フィールドを読み取ることで ETH の量を取得できます。

ERC-20 トークンの預け入れは、ETH の預け入れとは大きく異なります。ERC-20 トークンを預け入れるには、まずユーザーがブリッジ コントラクトにトークンの使用を許可する必要があります。ユーザーがこれを承認し、トークンをブリッジ コントラクトに預け入れると、コントラクトは「burnFrom()」関数を使用してユーザーのトークンをバーンするか、「transferFrom()」関数を使用してユーザーのトークンをコントラクトに転送します。

これを区別する 1 つの方法は、同じ関数内で if-else ステートメントを使用することです。もう 1 つの方法は、各シナリオを処理する 2 つの個別の関数を作成することです。ERC-20 入金関数を使用して ETH を入金しようとすると、これらの資金が失われる可能性があります。

ERC-20 デポジット リクエストを処理する場合、ユーザーは通常、デポジット関数への入力としてトークン アドレスを提供します。これは、トランザクション中に信頼できない外部呼び出しが発生する可能性があるため、大きなリスクをもたらします。ブリッジでサポートされているトークンのみを含むホワイトリストを実装することは、リスクを最小限に抑えるための一般的な方法です。ホワイトリストに登録されたアドレスのみが引数として渡されます。これにより、プロジェクト チームがすでにトークン アドレスをフィルター処理しているため、外部呼び出しが防止されます。

ただし、ネイティブ トークンにはアドレスがないため、ブリッジがネイティブ トークンのクロスチェーン転送を処理するときにも問題が発生する可能性があります。ゼロ アドレス (0x000...0) はネイティブ トークンを表します。ゼロ アドレスを関数に渡すと、正しく実装されていなくてもホワイトリスト検証をバイパスできるため、問題が発生する可能性があります。

ブリッジ コントラクトが「transferFrom」を呼び出してユーザー資産をコントラクトに転送すると、ゼロ アドレスに「transferFrom」関数が実装されていないため、ゼロ アドレスへの外部呼び出しは false を返します。ただし、コントラクトが戻り値を適切に処理しない場合は、トランザクションが引き続き発生する可能性があります。これにより、攻撃者がトークンをコントラクトに転送せずにトランザクションを実行する機会が生まれます。

誤った設定

ほとんどのブロックチェーン ブリッジでは、特権ロールがトークンとアドレスのホワイトリストまたはブラックリストへの登録、署名者の割り当てまたは変更、その他の重要な構成を担当します。一見些細な見落としでも大きな損失につながる可能性があるため、すべての構成が正確であることを確認することが重要です。

実際、設定ミスにより攻撃者が転送記録の検証をうまく回避した事件がありました。プロジェクト チームはハッキングの数日前にプロトコルのアップグレードを実施しましたが、これには変数の変更が含まれていました。この変数は、信頼できるメッセージの既定値を表すために使用されていました。この変更により、すべてのメッセージが自動的に証明済みとみなされ、攻撃者が任意のメッセージを送信して検証プロセスを通過できるようになりました。

橋のセキュリティを向上させる方法

上記で説明した 4 つの一般的なブリッジの脆弱性は、相互接続されたブロックチェーン エコシステムでセキュリティを確保する際の課題を示しています。これらの脆弱性のそれぞれに対処するには重要な考慮事項があり、すべてに当てはまる単一のプレイブックはありません。

たとえば、各ブリッジには独自の検証要件があるため、エラーのない検証プロセスを保証するための一般的なガイドラインを提供することは困難です。検証バイパスを防ぐ最も効果的なアプローチは、考えられるすべての攻撃ベクトルに対してブリッジを徹底的にテストし、検証ロジックが適切であることを確認することです。

要約すると、潜在的な攻撃に対して厳密なテストを実行し、ブリッジにおける最も一般的なセキュリティの脆弱性に特に注意を払うことが重要です。

終わりに

クロスチェーン ブリッジは、その価値の高さから、長い間攻撃者の標的となってきました。ブリッジの構築者は、徹底した事前展開テストを実施し、第三者による監査に参加することで、ブリッジのセキュリティを強化し、過去数年間ブリッジを悩ませてきた壊滅的なハッキングのリスクを軽減できます。ブリッジはマルチチェーンの世界では重要ですが、効果的な Web3 インフラストラクチャを設計および構築する際には、セキュリティを最優先に考慮する必要があります。

参考文献

ブロックチェーンブリッジとは何ですか?

クロスチェーン相互運用性とは何ですか?

人気の暗号ブリッジ3つとその仕組み

ラップされたトークンとは何ですか?

免責事項とリスク警告：このコンテンツは、一般的な情報と教育目的のみで「現状のまま」提供されており、いかなる表明や保証もありません。財務、法律、その他の専門的なアドバイスとして解釈されるべきではなく、特定の製品やサービスの購入を推奨することを意図したものでもありません。適切な専門アドバイザーから独自のアドバイスを求める必要があります。記事が第三者寄稿者によって寄稿されている場合、表明された見解は第三者寄稿者のものであり、必ずしもBinance Academyの見解を反映するものではないことにご注意ください。詳細については、こちらで完全な免責事項をお読みください。デジタル資産の価格は変動する可能性があります。投資の価値は下がったり上がったりする可能性があり、投資した金額が戻ってこない可能性があります。投資の決定はあなた自身の責任であり、Binance Academyはあなたが被る損失について責任を負いません。この資料は、財務、法律、その他の専門的なアドバイスとして解釈されるべきではありません。詳細については、利用規約とリスク警告をご覧ください。