要約
ブリッジはブロックチェーン分野における相互運用性を実現する根幹です。したがって、クロスチェーンブリッジ技術の安全性は非常に重要です。一般的なブリッジの安全脆弱性には、オンチェーンおよびオフチェーンの検証不足、ネイティブトークンの不適切な処理、設定ミスなどがあります。検証ロジックの妥当性を確保するために、すべての攻撃ベクトルに対してブリッジをテストすることを推奨します。
導入
ブリッジは二つのブロックチェーンを接続し、相互作用を可能にするプロトコルです。ブリッジを通じて、ユーザーはイーサリアムネットワークのDeFi活動に参加するためにビットコインを保有し、売却せずに目的を達成できます。
ブリッジはブロックチェーン分野における相互運用性の基盤です。さまざまなオンチェーン・オフチェーン検証を用いて機能しますが、そのために異なる安全脆弱性も存在します。
なぜブリッジの安全性が重要なのか？
ブリッジは通常、ユーザーがあるチェーンから別のチェーンへ移したいトークンを保持します。これらのブリッジはスマートコントラクトの形で展開され、クロスチェーン移行の蓄積に伴い、多くのトークンを保持します。この巨額の資産はハッカーの標的となり得ます。
また、多くのコンポーネントを含むため、ブリッジの攻撃面は広くなりがちです。不正者はクロスチェーンアプリを標的にし、大量の資金を奪取しようと強い動機を持っています。
CertiKの推定によると、2022年にはブリッジ攻撃により13億ドル超の損失が発生し、その年の総損失の36％を占めました。
一般的なクロスチェーンブリッジの安全脆弱性
ブリッジの安全性を高めるために、一般的なクロスチェーンブリッジの脆弱性を理解し、展開前にテストすることが非常に重要です。これらの脆弱性は主に以下の4つの側面から生じます。
オンチェーン検証不足
シンプルなブリッジ、特に特定のdApp向けに設計されたブリッジは、通常最低限のオンチェーン検証しか行いません。これらのブリッジは集中型バックエンドに依存し、基本的な操作（ミント、バーン、トークン移転など）を実行しますが、すべての検証はオフチェーンで行われます。
一方、他のタイプのブリッジはスマートコントラクトを用いてメッセージの検証とオンチェーン検証を行います。この場合、ユーザーが資金をチェーンに預けると、スマートコントラクトは署名付きのメッセージを生成し、取引内で署名を返します。この署名は入金の証明として用いられ、別のチェーンでの引き出しリクエストの検証に使われます。このフローは、リプレイ攻撃や偽造入金記録などのさまざまな安全攻撃を防ぐべきです。
しかし、オンチェーン検証に脆弱性があると、攻撃によって重大な損失が生じる可能性があります。例えば、ブロックチェーンがマークルツリーを用いて取引記録を検証している場合、攻撃者は偽造証明を生成できることになります。検証プロセスに脆弱性があれば、攻撃者は証明の検証を回避し、自分のアカウントに新たなトークンを鋳造できてしまいます。
一部のブリッジは「ラップトークン(wrapped tokens)」の概念を採用しています。例えば、ユーザーがイーサリアムからBNBチェーンへDAIを移す場合、DAIはイーサリアムのコントラクトから引き出され、BNBチェーン上で同量のラップDAIが発行されます。
しかし、この取引が正しく検証されていない場合、攻撃者は悪意のあるコントラクトを展開し、その機能を操作してラップされたトークンを誤ったアドレスにルーティングすることが可能です。
攻撃者はまた、被害者にクロスチェーンブリッジコントラクトの事前承認をさせ、「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インフラを設計・構築する際には、安全性を最優先に考える必要があります。 **$STORJ **$STO
129.29K 人気度
78.8K 人気度
43.2K 人気度
1.23K 人気度
15.51K 人気度
一般的なクロスチェーンブリッジのセキュリティ脆弱性には何がありますか？
要約
ブリッジはブロックチェーン分野における相互運用性を実現する根幹です。したがって、クロスチェーンブリッジ技術の安全性は非常に重要です。一般的なブリッジの安全脆弱性には、オンチェーンおよびオフチェーンの検証不足、ネイティブトークンの不適切な処理、設定ミスなどがあります。検証ロジックの妥当性を確保するために、すべての攻撃ベクトルに対してブリッジをテストすることを推奨します。
導入
ブリッジは二つのブロックチェーンを接続し、相互作用を可能にするプロトコルです。ブリッジを通じて、ユーザーはイーサリアムネットワークのDeFi活動に参加するためにビットコインを保有し、売却せずに目的を達成できます。
ブリッジはブロックチェーン分野における相互運用性の基盤です。さまざまなオンチェーン・オフチェーン検証を用いて機能しますが、そのために異なる安全脆弱性も存在します。
なぜブリッジの安全性が重要なのか？
ブリッジは通常、ユーザーがあるチェーンから別のチェーンへ移したいトークンを保持します。これらのブリッジはスマートコントラクトの形で展開され、クロスチェーン移行の蓄積に伴い、多くのトークンを保持します。この巨額の資産はハッカーの標的となり得ます。
また、多くのコンポーネントを含むため、ブリッジの攻撃面は広くなりがちです。不正者はクロスチェーンアプリを標的にし、大量の資金を奪取しようと強い動機を持っています。
CertiKの推定によると、2022年にはブリッジ攻撃により13億ドル超の損失が発生し、その年の総損失の36％を占めました。
一般的なクロスチェーンブリッジの安全脆弱性
ブリッジの安全性を高めるために、一般的なクロスチェーンブリッジの脆弱性を理解し、展開前にテストすることが非常に重要です。これらの脆弱性は主に以下の4つの側面から生じます。
オンチェーン検証不足
シンプルなブリッジ、特に特定のdApp向けに設計されたブリッジは、通常最低限のオンチェーン検証しか行いません。これらのブリッジは集中型バックエンドに依存し、基本的な操作（ミント、バーン、トークン移転など）を実行しますが、すべての検証はオフチェーンで行われます。
一方、他のタイプのブリッジはスマートコントラクトを用いてメッセージの検証とオンチェーン検証を行います。この場合、ユーザーが資金をチェーンに預けると、スマートコントラクトは署名付きのメッセージを生成し、取引内で署名を返します。この署名は入金の証明として用いられ、別のチェーンでの引き出しリクエストの検証に使われます。このフローは、リプレイ攻撃や偽造入金記録などのさまざまな安全攻撃を防ぐべきです。
しかし、オンチェーン検証に脆弱性があると、攻撃によって重大な損失が生じる可能性があります。例えば、ブロックチェーンがマークルツリーを用いて取引記録を検証している場合、攻撃者は偽造証明を生成できることになります。検証プロセスに脆弱性があれば、攻撃者は証明の検証を回避し、自分のアカウントに新たなトークンを鋳造できてしまいます。
一部のブリッジは「ラップトークン(wrapped tokens)」の概念を採用しています。例えば、ユーザーがイーサリアムからBNBチェーンへDAIを移す場合、DAIはイーサリアムのコントラクトから引き出され、BNBチェーン上で同量のラップDAIが発行されます。
しかし、この取引が正しく検証されていない場合、攻撃者は悪意のあるコントラクトを展開し、その機能を操作してラップされたトークンを誤ったアドレスにルーティングすることが可能です。
攻撃者はまた、被害者にクロスチェーンブリッジコントラクトの事前承認をさせ、「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インフラを設計・構築する際には、安全性を最優先に考える必要があります。 **$STORJ **$STO