世界的に有名なCosmosエコシステムは、最大かつ最も注目されるブロックチェーンネットワークの1つとして優先的にブロックチェーンの相互運用性に重点を置いています。この焦点は、さまざまなブロックチェーン間のシームレスなコミュニケーションを促進する上で重要です。このエコシステムには、CelestiaやdYdX v4などの主要プロジェクトがあり、すべてCosmos SDKとIBCプロトコルを使用して開発されています。開発者の間でCosmosのコンポーネントの好みが高まっていることから、エコシステム内のセキュリティ問題が拡大しています。その例として、Cosmos SDKのDragonfruitの脆弱性が挙げられますが、これは多くの主要なパブリックブロックチェーンでの運用を妨げました。

Cosmosのコアコンポーネントの分散構造を考慮すると、開発者はしばしば特定の機能要件に基づいてこれらのコンポーネントを適応および拡張する必要があります。これにより、Cosmosエコシステム内でセキュリティの課題が分散することになります。その結果、Cosmosエコシステム内の現在のセキュリティ状況を理解し、これらのセキュリティ懸念を解決するための構造化されたアプローチが喫緊の課題となっています。この記事では、Cosmosエコシステム内の現在のセキュリティ状況について包括的な分析を行い、効果的な対応戦略を概説することを目的としています。

CertiKチームは、継続的な研究開発を通じて、Cosmosネットワークおよびより広範なWeb3エコシステムのセキュリティを強化することに取り組んでいます。定期的なセキュリティレポートや技術研究の最新情報を通じて、調査結果や洞察を共有することを楽しみにしています。何かご質問があれば、いつでもお問い合わせください。

こちらが「Cosmosエコシステムセキュリティガイド」の全文です👇。

コスモスの概要

世界で最も著名なブロックチェーンエコシステムの1つと見なされているCosmosは、オープンソース、スケーラブル、およびクロスチェーンネットワーク機能で際立っています。CometBFTチームによって開発され、元々Tendermintとして知られていたCosmosは、情報の孤立を排除し、さまざまなブロックチェーン間の相互運用性を促進することを目指しています。複数のブロックチェーンネットワークが共存する時代において、クロスチェーンの相互作用が以前よりもますます重要となっています。

Cosmosは、特に特定の垂直焦点を持つパブリックチェーンにとって特に有益な効率的なクロスチェーンモデルを提供することで、自らを区別しています。モジュラーブロックチェーンインフラストラクチャはアプリケーション開発者に力を与え、彼らが特定の要件に合致するパブリックチェーンを選択して利用する柔軟性を提供します。

Cosmosエコシステムの中心にあるのは、異なる独立したブロックチェーン間のアプリケーションやプロトコルを接続するInter-Blockchain Communication（IBC）プロトコルです。これにより、資産やデータのシームレスな転送だけでなく、Cosmosのビジョンである「ブロックチェーンのインターネット」の実現にも貢献しています。このコンセプトは、拡張や相互作用のために相互接続された、自律的で簡単に開発できるブロックチェーンの広大なネットワークを想定しています。

CertiKのCosmosセキュリティへの参加と研究

長期間にわたり、CertiKはCosmosエコシステムの研究に深く関与してきました。私たちのチームは、この環境内でのセキュリティ課題に取り組むための実践的な経験を積んできました。このレポートでは、Cosmosエコシステムのセキュリティに関する私たちの洞察と発見を共有し、Cosmos SDKのセキュリティ、IBCプロトコルのセキュリティ、CometBFTのセキュリティ、CosmWasmのセキュリティに焦点を当てます。私たちの議論は、Cosmosエコシステムの基本的な構成要素からその基盤およびアプリケーションチェーンまでをカバーします。関連する問題を検討し推測することで、Cosmosエコシステム内の重要なセキュリティアスペクトの包括的で底上げの分析を提示することを目指しています。

Cosmosエコシステムの複雑さと多様性を考慮すると、さまざまなセキュリティ上の課題に直面しています。このレポートでは、主にCosmosの生態系に対する最も特徴的で重要な脅威に焦点を当てています。その他のセキュリティ上の側面に関する情報や議論については、CertiKのセキュリティエンジニアにご相談いただくことをお勧めします。

背景

CometBFT: そのコアでクロスチェーンのスケーラビリティを向上させる

インターチェーンのスケーラビリティの中心には、セキュリティ、分散、およびインターチェーンエコシステムの整合性を確保するために不可欠な最先端のコンセンサスアルゴリズムであるCometBFTがあります。 このアルゴリズムは、CometBFTコア（基本的なコンセンサスエンジン）とユニバーサルアプリケーションブロックチェーンインターフェース（ABCI）の2つの主要コンポーネントの組み合わせです。 PBFT（Practical Byzantine Fault Tolerance）とBonded Proof of Stake（PoS）の要素を組み合わせることで、CometBFTはノードを同期させて正確な取引記録を維持し、それによってインターチェーン環境内の検証者コンセンサスにおいて重要な役割を果たしています。

Cosmos SDK: モジュラリティを活用したブロックチェーン開発の加速

Cosmos SDKは、ブロックチェーンの開発を簡素化し、加速させる強力なツールキットとして位置付けられています。そのモジュラーデザインとプラグイン可能な機能により、開発者はCometBFTコンセンサスアルゴリズムの上に独自のブロックチェーンや機能コンポーネントを構築することができます。このアプローチは開発を容易にするだけでなく、開発サイクルを大幅に短縮します。SDKの効果は、Cronos、Kava、そして最近リリースされたdYdX V4を含む多数のプロジェクトでの採用によって裏付けられています。将来、Cosmos SDKはそのモジュラリティを向上させ、新機能を導入することで、より洗練されたモジュラーアプリケーションの作成を可能にし、より広範で堅固なエコシステムを育成する予定です。

IBC Protocol: ブロックチェーン間の相互運用性とスケーラビリティを推進する

Inter-Blockchain Communication（IBC）プロトコルは、Cosmosネットワーク内のブロックチェーン間で安全で分散化された許可なしのデータ転送を促進する上で中心的な役割を果たしています。Cosmosはリレーテクノロジーを介して接続された複数の独立した並行ブロックチェーンから成る分散型ネットワークであるため、IBCプロトコルの役割はスケーラビリティと相互運用性の向上において中心的です。Interchain Foundationの現在の焦点は、IBCプロトコルのこれらの側面を改善することであり、Cosmosエコシステム内のブロックチェーン、アプリケーション、スマートコントラクト間のシームレスな相互作用を強化することを目指しています。

CosmWasm：分散アプリケーションの展開を支援

CosmWasm（Cosmos WebAssembly）は、Cosmosエコシステム向けにカスタマイズされたスマートコントラクトフレームワークです。WebAssemblyに基づいており、特定の許可を必要とせずに開発者が分散型アプリケーションを展開できるようにします。このフレームワークにより、ブロックチェーン開発者は製品開発とブロックチェーン開発を切り離すことができ、バリデータのアップグレードの負担を軽減します。CosmWasmの特長には、モジュラーアーキテクチャ、Cosmos SDKとの統合、およびクロスチェーン通信機能が含まれます。比較的成熟しているCosmos SDKとIBCプロトコルは、現在のCosmosエコシステムで広く利用されています。

コスモスエコシステム内での適応とカスタマイズ

Cosmosエコシステムのチェーン開発者にとって、Cosmos SDKはほとんどのカスタマイズニーズを満たしています。クロスチェーンアクティビティ中、チェーン開発者は特別な操作やパフォーマンス最適化のためにIBCモジュールをカスタマイズすることができます。一部のチェーンはCometBFT Coreのような基礎エンジンを変更しますが、スペースの制約によりこのレポートではそのような変更の詳細な議論は避けられています。したがって、このリサーチは主にCosmos SDKとIBCプロトコルの技術的ニュアンスやセキュリティの考慮事項に焦点を当てています。

Cosmos SDKセキュリティガイド

Cosmos SDKセキュリティガイドは、ブロックチェーンアプリケーションや分散型プロトコルを開発するための高度なフレームワークであるCosmos SDKのセキュリティに関する包括的な概要を提供しています。Interchain Foundationによって作成されたこのフレームワークは、Cosmosネットワークにとって重要であり、相互接続された複数のブロックチェーンから成る広大なネットワークです。

Cosmos SDKは、多様なブロックチェーン間のシームレスな相互作用を促進しつつ、カスタマイズされたブロックチェーンアプリケーションの作成を効率化するよう設計されています。その注目すべき特徴には、モジュラー構造、幅広いカスタマイズ可能性、コンセンサスのためのCometBFT Coreとの統合、IBCインタフェースの実装などが含まれており、これらすべてが開発者に魅力をもたらしています。Cosmos SDKの大きな強みの1つは、CometBFT Coreコンセンサスエンジンへの依存であり、堅牢なセキュリティ対策を提供しています。このエンジンは、ネットワークを悪意のある攻撃から守り、ユーザーの資産やデータを保護する上で重要な役割を果たしています。SDKのモジュラー性は、ユーザーが簡単に独自のモジュールを作成できるようにする力を与えています。ただし、Cosmos SDKを使用してアプリケーションを展開する際には、セキュリティの脆弱性が依然として発生する可能性があるため、開発者は慎重である必要があります。

セキュリティ監査の観点から、潜在的なセキュリティ脅威を複数の視点から徹底的に評価することが重要です。それに対し、セキュリティ研究では、重要な影響を及ぼす可能性のある脆弱性を特定することに重点が置かれます。このアプローチは、主要なセキュリティ脅威を迅速に緩和し、SDKを統合するサービスにより効果的な支援を提供することを目的としています。深刻なリスクをもたらし、広範囲な影響を持つ脆弱性を特定し、精査することが重要です。

Cosmos SDK内の焦点は、Cosmosエコシステムにとって不可欠なABCIインターフェイスです。このインターフェースは、BeginBlock、EndBlock、CheckTx、およびDeliverTxの4つの主要コンポーネントで構成されています。BeginBlockとEndBlockは、個々のブロックの実行ロジックに直接関与しています。一方、CheckTxとDeliverTxは、Cosmosエコシステム内でのメッセージ伝送のための基本データ構造であるsdk.Msgの処理に関与しています。

セキュリティの脆弱性を理解し対処するには、最初にCosmosエコシステムにおけるトランザクションのライフサイクルを把握する必要があります。トランザクションはユーザーエージェントから発信され、そこで作成、署名され、その後ブロックチェーンノードにブロードキャストされます。ノードはCheckTxメソッドを使用して、署名、送信者の残高、トランザクションのシーケンス、提供されたガスなどのトランザクションの詳細を検証します。有効なトランザクションはメンプールにキューイングされ、ブロックに含まれるのを待ちますが、無効なものは拒否され、エラーメッセージがユーザーに中継されます。ブロック処理中には、トランザクショナルな一貫性と決定論を確保するためにDeliverTxメソッドが適用されます。

Cosmos SDKでは、取引ライフサイクルは、生成、検証、ブロックへの組み込み、状態の変更、最終確定を含む多段階のプロセスです。このプロセスは、次のステップで概説できます。

1. 取引の作成: ユーザーは、Command Line Interfaces（CLI）やフロントエンドクライアントなどのさまざまなツールを使用して取引を生成します。

2. Mempoolへの追加: 作成されると、トランザクションはメンプールに入ります。ここで、ノードはABCインターフェース(Application BlockChain Interface)メッセージであるCheckTxをアプリケーション層に送信して妥当性をチェックします。トランザクションはバイト形式からTx形式にデコードされます。トランザクション内の各sdk.Msgは、ValidateBasic()関数による事前の状態チェックを受けます。さらに、アプリケーションにanteHandlerが含まれている場合、そのロジックはrunTx関数の実行の前に実行され、sdk.Msgコンテンツの処理のためにRunMsgs()関数に移行します。成功したCheckTxにより、トランザクションはローカルメンプールにキューイングされ、次のブロックに含まれる準備が整い、同時にP2Pを介してピアノードにブロードキャストされます。

3. 提案されたブロックへの含まれて: 各ラウンドの始めに、提案者は最近の取引を含むブロックを組み立てます。コンセンサスの維持を担当する検証者は、このブロックを承認するか、空のブロックを選択します。

4. State Changes: CheckTx に類似して、DeliverTx プロセスはブロックトランザクションを反復処理します。ただし、'Deliver' モードで動作し、状態変更を実行します。MsgServiceRouter は異なるトランザクションメッセージを各モジュールに誘導し、各メッセージは Msg サーバーで処理されます。メッセージの実行後、さらなるチェックがトランザクションの妥当性を確認します。チェックに失敗した場合、状態は以前の状態に戻ります。ガスメーターは実行中に消費されたガスを追跡します。ガス関連のエラー（ガスが不足しているなど）は、実行失敗と同様に状態変更の回復につながります。

5. ブロックコミットメント: 十分なバリデーターの投票を受け取ると、ノードは新しいブロックをブロックチェーンにコミットします。このアクションにより、アプリケーションレイヤーでの状態遷移が最終確定され、取引プロセスが完了します。

)

[このセクションには、Cosmosエコシステム内の取引ライフサイクルを示す図が含まれています。]

[後述のセクションでは、Cosmos SDKのキーABCIの具体的な実行ロジックが提供されており、後で議論される脆弱性を理解し分析するのに役立ちます。]

)

一般的な脆弱性カテゴリ

脆弱性の分類を理解する前に、脆弱性の危険レベルを基本的に分ける必要があります。これにより、高リスクのセキュリティ脆弱性をより良く特定し、潜在的なセキュリティリスクを回避するのに役立ちます。

)

危険レベルと影響範囲を考慮すると、通常、以下のリスクを引き起こすことができる重大度の高いセキュリティ脆弱性であるCriticalおよびMajorに主に焦点を当てています。

1. チェーン停止操作
2. 財務的損失
3. システムの状態や正常な動作に影響を与える

これらの危険の原因は、しばしば次の種類のセキュリティの脆弱性です:

1. サービス拒否
2. 状態設定が正しくありません
3. 検証の欠如または不合理
4. ユニークさの問題
5. コンセンサスアルゴリズムの問題
6. 実装上の論理的な欠陥
7. 言語機能の問題

Cosmosエコシステムの脆弱性分析

Cosmosエコシステムは、モジュラー構造で知られており、しばしばチェーン内でのモジュールの相互利用や相互呼び出しに遭遇します。この複雑さにより、脆弱性トリガーパスと場所変数が一貫していないシナリオが生じます。これらの脆弱性を理解する上で、トリガーパスだけでなく、脆弱性の重要な変数の制御可能なパスも考慮することが重要です。この二重焦点は、脆弱性モデルのより良い定義と分類に役立ちます。

チェーン停止操作：原因と種類

チェーンの停止は通常、単一ブロックの実行中に発生した問題が原因です。ただし、Cosmosの歴史には、合意のセキュリティの脆弱性が修復のためにアクティブなチェーンの停止を必要とする事例が含まれています。これらの問題は2つの異なるカテゴリに分類されます。

最初のタイプは、サービス拒否脆弱性で一般的に見られます：これらは、不適切なクラッシュ処理とユーザーに影響を受けるループ境界操作の結果であることがよくあります。このような脆弱性は、チェーンの一時停止や著しく遅延する可能性があります。

Cosmos SDKとCometBFTは、Cosmosエコシステムの重要なインフラストラクチャであり、Cosmosのベースチェーンだけでなく、それらのアーキテクチャに基づくさまざまなアプリケーションチェーンでも使用されています。すべてのチェーンはCometBFTのABCIインターフェイスの規則に従っています。攻撃の対象は、一般にBeginBlockおよびEndBlockインターフェースにトレースバックできるため、チェーンの停止につながるセキュリティの脆弱性のほとんどは、ブロックコードの実行に直接影響を与える問題です。

二番目のタイプの状況は、合意に影響を与える脆弱性に関連しており、これらはしばしば様々なチェーン全体での実装に関連し、ロジック処理検証、時間の校正、およびランダム性に関する問題を含みます。これらの脆弱性は、ブロックチェーンの分散主義の原則に直接打撃を与えます。最初は深刻には見えないかもしれませんが、悪意のある行為者の手に落ちると、それは重大なセキュリティ脅威となります。

最初のタイプの例

Example 1: SuperNovaプロジェクトの脆弱性分析

脆弱性の背景:SuperNovaプロジェクト内で配布を作成する過程で、アドレス検証の欠如から重大な問題が発生します。この見落としは、運用の失敗につながり、その結果、経済的損失につながる可能性があります。具体的には、トークン生成にとって極めて重要なミントモジュールは、ステークされた量に依存しています。ただし、このプロセスはエラーの影響を受けやすいです。例えば、指定されたプールが存在しない場合や、コントラクトアドレスの入力に誤りがある場合、ミンティングモジュールの誤動作につながる可能性があります。このようなエラーは、ブロックチェーンの運用全体を停止する可能性があります。さらに、報酬プールモジュールでは、プールコントラクトアドレスの検証が欠如しています。この見落としは、配布操作の失敗がブロックチェーンの即時停止を引き起こす可能性があることを意味します。

脆弱性の位置: SuperNova GitHub Link

脆弱なコードスニペット：

脆弱性トリガーパス:

BeginBlocker (/x/mint/keeper/abci.go)

Keeper.DistributeMintedCoin

Keeper.distributeLPIncentivePools

PoolIncentiveKeeper.GetAllIncentivePool (/x/mint/keeper/keeper.go)

脆弱性パッチ:

https://github.com/Carina-labs/nova/commit/538abc771dea68e33fd656031cbcf2b8fe006be0

パッチは、mintモジュールではなく、poolincentive（x/poolincentive/types/msgs.go）のメッセージハンドリングモジュールにあります。 MsgCreateCandidatePoolメッセージにアドレス検証を追加し、誤ったアドレスの可能性を排除しました。

Example 2: Cosmos Interchain Security Project

プロジェクトアドレス：Cosmos Interchain Security GitHub Link

Vulnerability background: Validators can slow down the provider chain by submitting multiple AssignConsumerKey messages in the same block. In the x/ccv/provider/keeper/key_assignment.go file, the AssignConsumerKey function allows validators to assign different consumerKeys to approved consumer chains. The consumerAddrsToPrune AddressList increases by one element to perform this operation. Since this AddressList is iterated in the EndBlocker in x/ccv/provider/keeper/relay.go, attackers can exploit it to slow down the provider chain. For this attack, the malicious actor can create transactions with multiple AssignConsumerKey messages and send them to the provider chain. The cardinality of the consumerAddrsToPrune AddressList will be the same as the sent AssignConsumerKey messages. Therefore, the execution of EndBlocker will take more time and resources than expected, slowing down or even stopping the provider chain.

脆弱性の場所：Cosmos Interchain Security GitHubリンク

脆弱性コードセグメント：

脆弱性トリガーパス：

msgServer.AssignConsumerKey

Keeper.AssignConsumerKey

AppModule.EndBlock

EndBlockCIS

ハンドルリーディングVSCMaturedパケット

ハンドルVSCMaturedPacket

PruneKeyAssignments

Example 3: Quicksilver Project - Airdrop Module

脆弱性の背景: BeginBlockerとEndBlockerは、モジュール開発者が自分のモジュールで実装できるオプションのメソッドです。それらはそれぞれブロックの開始と終了時にトリガーされます。BeginBlockとEndBlockのメソッドでエラーを処理するためにクラッシュを使用すると、エラーが発生した場合にチェーンが停止する可能性があります。EndBlockerは、未完了のエアドロップを解決するためにモジュールに十分なトークンがあるかどうかを考慮していませんでした。これはクラッシュを引き起こし、チェーンを停止させる可能性があります。

Vulnerability location: Quicksilver GitHub リンク

Vulnerability Code Segment:

脆弱性パッチ：AppModule.EndBlock

Keeper.EndBlocker

Keeper.EndZoneDrop

脆弱性パッチ: https://github.com/quicksilver-zone/quicksilver/blob/20dc658480b1af1cb323b4ab4a8e5925ee79a0ed/x/airdrop/keeper/abci.go#L16

パニック処理コードが削除され、エラーロギングに置き換えられました。

例4：Cosmos Interchain Securityプロジェクト

プロジェクトアドレス: Cosmos Interchain Security GitHubリンク

脆弱性の背景: 攻撃者は、プロバイダーチェーンの報酬アドレスに複数のトークンを送信することで、サービス拒否攻撃を実行できます。コンシューマチェーンのEndBlocker実行フローでは、x/ccv/consumer/keeper/distribution.goで定義されたSendRewardsToProvider関数がtstProviderAddr内のすべてのトークンの残高を取得し、プロバイダーチェーンに送信します。これを実現するには、報酬アドレスにあるすべてのトークンを反復処理し、それぞれをIBC経由でプロバイダーチェーンに送信する必要があります。誰でも報酬アドレスにトークンを送信できるため、攻撃者は、トークンファクトリモジュールを備えたチェーンを使用するなど、多数の異なるdenomトークンを作成して送信し、サービス拒否攻撃を開始することができます。したがって、EndBlockerの実行には予想よりも多くの時間とリソースが必要であり、コンシューマチェーンが遅くなったり、停止したりすることさえあります。

脆弱性の場所: Cosmos Interchain Security GitHubリンク

Vulnerability Code Segment:

脆弱性トリガーパス:

AppModule.EndBlock

EndBlock

EndBlockRD

プロバイダーに報酬を送信する

第二のタイプの状況

この種のコンセンサスの問題は、直ちに深刻な影響をもたらす可能性はないかもしれませんが、ブロックチェーン全体の基本原則やシステムを考慮すると、あるいは特定のシナリオからこれらの脆弱性を見ると、その影響や害は他の従来の脆弱性と遜色ないかもしれません。さらに、これらの脆弱性には共通の特徴があります。

例 1

脆弱性の背景：Cosmos SDKセキュリティアドバイザリJackfruit

Cosmos SDKのx/authzモジュールのValidateBasicメソッドにおける非決定論的な動作は、簡単にコンセンサスの停止につながる可能性があります。x/authzモジュールのMsgGrantメッセージ構造には、ユーザー定義の認可によって付与された有効期限が含まれています。Grant構造体のValidateBasic()の検証プロセスでは、ブロックの時間情報ではなく、ノードのローカル時間情報とその時間情報を比較します。ローカル時間が非決定論的であるため、ノード間でタイムスタンプが異なる場合があり、コンセンサスの問題が発生する可能性があります。

Vulnerability announcement:

• Cosmosフォーラムリンク1

• Cosmosフォーラムリンク2

• Cosmos SDK GitHubセキュリティアドバイザリーリンク

Vulnerability Code Segment:

脆弱性パッチ: Cosmos SDK GitHub Compare Link

タイムスタンプのような問題は、Cosmos SDKなどの基本的なコンポーネントにだけでなく、さまざまなアプリケーションチェーンでも発生しています。

例2

脆弱性の背景: SuperNova、novaプロジェクト

プロジェクトアドレス: SuperNova GitHub Link

time.Now()を使用すると、オペレーティングシステムのタイムスタンプが返されます。 ローカルタイムは主観的であり、したがって非決定的です。個々のノードのタイムスタンプにはわずかな違いがある可能性があるため、チェーンは合意に達することができないかもしれません。 ICAControlモジュールでは、トランザクション送信関数がタイムスタンプを取得するためにtime.Now()を使用します。

脆弱性の位置: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/icacontrol/keeper/send_msgs.go#L14

脆弱性コードセグメント：

脆弱性パッチ:

ローカルタイムスタンプの使用からブロックタイムの使用に変更しました。

timeoutTimestamp := timeです。Now()です。Add(time.分 * 10)。UnixNano() _, err = k.IcaControllerKeeper.SendTx(ctx, chanCap, connectionId, portID, packetData, uint64(timeoutTimestamp))

timeoutTimestamp := uint64(ctx.BlockTime().UnixNano() + 10*time.Minute.Nanoseconds()) _, err = k.IcaControllerKeeper.SendTx(ctx, chanCap, connectionId, portID, packetData, uint64(timeoutTimestamp)）

Case Three:

脆弱性の背景：BandChainプロジェクトのOracleモジュール

プロジェクトURL: BandChain GitHubリポジトリ

コードリポジトリ内のコメントによると、オラクルモジュールは、オラクルプロトコルの違反者に対する処罰措置を実装するためにステーキングの前に実行される必要があります。しかし、コードでは、シーケンスが逆になっています：SetOrderEndBlockers関数では、ステーキングモジュールがオラクルモジュールの前に実行されます。ステーキングモジュールがオラクルモジュールの前に実行されると、オラクルモジュールで完了した検証に基づいてペナルティを実施することが不可能になります。

Vulnerability Location: BandChain GitHubのコードスニペット

Vulnerability Code Segment:

脆弱性は、実際の実装とコメントが矛盾している点にあり、オラクルモジュールはステーキングモジュールの前に配置する必要があります。

ケースフォー:

Vulnerability Background: Accesscontrol Module in the Sei Cosmos Project

Project URL: Sei Cosmos GitHub Repository

Cosmos関連の複数のインスタンスで、Go言語のmap型が使用され、そのイテレーションが行われています。Goのmapのイテレーションが非決定的であるため、これによってノードが異なる状態に到達し、それが結果的にコンセンサスの問題を引き起こし、それによってチェーンの動作が停止する可能性があります。より適切な方法は、mapのキーをスライスにソートし、ソートされたキーをイテレーションすることです。このような問題は、言語の機能の適用から生じる共通のものです。

x/accesscontrol/keeper/keeper.goのBuildDependencyDagの実装では、anteDepSetノードを反復処理しています。Go言語のマップ反復の非決定的な動作のため、ValidateAccessOpは2種類の異なるエラーを引き起こす可能性があり、これがコンセンサスの失敗につながる可能性があります。

脆弱性の位置: Sei Cosmos GitHubのコードスニペット

Vulnerability Code Segment:

これらのケースから、チェーンを停止させる脆弱性が通常最も有害であることが明らかです。その原因となるロジックは、ブロックチェーン内の個々のブロックの実行フローに直接影響を与えることまで遡ることができます。一方、コンセンサスセキュリティの脆弱性は、通常、チェーンが積極的に修正を実装するために停止する結果となり、その原因となるロジックはブロックチェーンの全体的な運用フローと状態に影響を与えることに遡ることができます。これは、金銭的損失を招く脆弱性の焦点とは異なります。危険な影響は、問題の発生の論理経路に基づいて判断されるのではなく、むしろ資金の所有者、関与する金額、範囲、および資金に影響を与える方法に焦点を当てています。

資金の損失

sdk.MsgやIBCメッセージの論理的な処理において、資本の損失の問題がよく見られます。もちろん、ブロックチェーンの運用を停止させる原因の一部として資本の損失を引き起こす脆弱性も存在します。具体的な影響は特定の脆弱性に依存しますが、ここでは前者に焦点を当てます。さらに、IBCはCosmosエコシステムの非常に重要な構成要素であるため、IBCには避けられない脆弱性が関係してきます。IBCの攻撃面やそれに対応する脆弱性の詳細については、次の章で議論します。

キャピタルロスは、ガス消費、資金がロックされて引き出せない、送金中の資金の損失、計算ロジックのエラーによる資金の損失、資金保管IDの一意性を確保できないなどのシナリオで一般的に遭遇します。

ここでは、SuperNovaプロジェクトを例に取り、3つの関連する脆弱性を分析します。

脆弱性の背景：SuperNovaプロジェクト

プロジェクトURL: https://github.com/Carina-labs/nova

ゾーンの小数点以下の桁数が18を超えると、資金がロックされる可能性があります。このプロジェクトのコードでは、ゾーンの小数点以下の桁数に上限がなく、18を超えることがあります。ClaimSnMessageでは、ユーザーが自分の共有トークンを請求したい場合、ClaimShareTokenが使用されます。しかし、ゾーンの小数点以下の桁数が18を超えると、変換に失敗し、システムから資産を抽出することができなくなります。そのため、ゾーンの小数点以下の桁数を制御することで、トランザクションのクラッシュと失敗を直接的に引き起こすことができます。

脆弱性の位置: https://github.com/Carina-labs/nova/blob/v0.6.3/x/gal/keeper/claim.go#L167

脆弱性コードフラグメント：

脆弱性トリガーパス：

msgServer.ClaimSnAsset

Keeper.ClaimShareToken

Keeper.ConvertWAssetToSnAssetDecimal

precisionMultiplier

• 脆弱性の背景：SuperNovaプロジェクト

プロジェクトアドレス：https://github.com/Carina-labs/nova/

ゾーンの一意性が確認されていません。登録された地域では、リージョンIDを使用してベーストークン（BaseDenom）の一意性を確認してください。各地域のBaseDenomはユニークである必要があります。ベーストークンの値が誤って設定されていると、資金の損失につながります。RegisterZoneでベーストークンを設定する前に、プロジェクトはすべてのメインゾーンでBaseDenomが一意であることを確認していませんでした。それ以外の場合、同じ名前のBaseDenomを含む他の悪意のあるゾーンにユーザーが資金を保管する可能性があり、資金の損失につながります。

Vulnerability location: https://github.com/Carina-labs/nova/blob/v0.6.3/x/icacontrol/keeper/msg_server.go#L99

脆弱なコードスニペット：

バグパッチ：DenomDuplicateCheckチェックの追加

さらに、チェーンが停止する最初のケースは、ミントの失敗につながるクラッシュが原因であり、これも資本損失の一形態です。

• 脆弱性の背景：Supernovaプロジェクト

プロジェクトアドレス: https://github.com/Carina-labs/nova/

状態の更新がありません。 IcaWithdraw（）メソッドでは、トランザクションが失敗し、バージョンの状態が変更されない場合、WithdrawRecordにアクセスできなくなり、対応する資金を引き出すことができません。 より一般的な理解としては、SendTxの前に状態が設定され、失敗後に状態が変更されないため、資金の引き出しに失敗し、次回も引き出すことができません。

脆弱性の位置: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/gal/keeper/msg_server.go#L356

脆弱なコードスニペット:

この抜粋に基づくと、資金に関連する主要なロジックは、さまざまなメッセージの処理に主に依存しています。もちろん、BeginBlock実行プロセスでの鋳造操作に関する最初のシナリオのようなケースもあります。これらの操作が失敗すると、それは財務上の損失につながることもあります。全体として、財務操作に関わるコードモジュールに焦点を当てることで、そのような脆弱性を発見する可能性を大幅に高めることができます。

システムの状態や通常の運用に影響を与える

このカテゴリの問題の範囲は非常に広いです。私たちが議論したリスクの最初の2つのタイプは、システムの状態や通常の運用に影響を与える脆弱性のサブセットとして考えられることもあります。これに加えて、もっと危険なのはさまざまな論理的な脆弱性です。これらの脆弱性は、プロジェクトのビジネスロジックに応じて異なるセキュリティリスクを大きく生み出します。ただし、Cosmos SDKコンポーネントの構築とそのモジュール性の類似性により、特定のコード実装において類似したエラーがしばしば発生します。ここでは、一般的な脆弱性のいくつかをリストアップします。

- sdk.Msgタイプの変数検証が不完全です:

さまざまなプロジェクトが、sdk.Msgに基づいたさまざまな派生型を実装しているため、Cosmos SDKではすべての既存の型の要素が適切にチェックされているわけではありません。これにより、重要な埋め込み変数のチェックが省略され、それによってある種のセキュリティリスクが引き起こされています。

Case Study: Cosmos SDK Security Advisory Barberry

脆弱性の背景: MsgCreatePeriodicVestingAccount.ValidateBasicには、アカウントの状態を評価するためのメカニズムが不足しています。たとえば、アカウントがアクティブであるかどうかなど。x/authで定義されたPeriodicVestingAccountでは、攻撃者が被害者のアカウントを悪意のある所有者のアカウントに初期化する可能性があります。このアカウントは入金を許可しますが、引き出しを禁止します。ユーザーが自分のアカウントに資金を預けると、これらの資金は永久にロックされ、ユーザーは引き出すことができません。

脆弱性パッチ:

https://forum.cosmos.network/t/cosmos-sdk-security-advisory-barberry/10825

https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-j2cr-jc39-wpx5

https://github.com/cosmos/cosmos-sdk/compare/v0.47.3-rc.0...v0.47.3

https://github.com/cosmos/cosmos-sdk/pull/16465

脆弱なコードスニペット：

このほかにも、Cosmos-SDKセキュリティアドバイザリElderflowerとCosmos-SDKセキュリティアドバイザリJackfruitにおいてValidateBasicステージの問題が存在していました。前者はValidateBasic呼び出しの直接の省略に苦しんでいた一方、後者はメッセージ内のタイムスタンプ変数の検証に関する問題がありました。アプリケーションチェーンでは、このような問題がさらに一般的です。Ethermint、pstake-native、quicksilverなどのプロジェクトでは、それぞれのメッセージ処理検証手段において同様のセキュリティ脆弱性に直面しています。

検証タイプ以外にも、sdk.Msgの処理ロジックで遭遇する問題があります。例えば、大規模なガス消費を伴う操作、ループ、合理的でないクラッシュ処理などです。メッセージの処理チェーンには対応する回復メカニズムがありますが、それらの危険レベルは完全なチェーンのシャットダウンよりもやや低くなります。ただし、それでもシステムの正常な運用に影響を与えたり、チェーン上で資金の損失を引き起こす可能性があります。

一般的な脆弱性の種類

特定のプロジェクト操作に固有の脆弱性を除いて、より一般的な脆弱性モデルがあります。例えば、資金の損失の第3のケースは、メッセージを送信する前に状態を変更する操作です。この種の脆弱性は、スマートコントラクトでのものと類似しており、資金を送金する前に状態を変更することが、再入や誤った状態の継続などの問題を引き起こす可能性があります。状態設定がメッセージの送信と密接に関連しているシナリオは、ブロックチェーンにおいて非常に一般的であり、多くの重要な脆弱性がこのような問題から発生しています。また、除算によるゼロエラーやガス消費の回避、既知の脆弱性を持つバージョンの使用など、計算セキュリティの脆弱性もあり、これらはすべてシステムの状態や正常な動作に影響を与える可能性があります。

ユニークさの問題

ブロックチェーン上では多数の読み取りおよび書き込み操作が行われるため、一部の機能では命名の一意性が非常に重要です。例えば、先ほどの資金損失の2つ目のケースは、独自性の問題です。さらに、文字列やバイト配列などのキーを表す変数のプレフィックスの構成は、リスクをもたらす可能性があります。わずかな見落としにより、名前が誤解され、資金の損失やコンセンサスエラーなどの問題につながる可能性があります。

言語機能の問題

これらはより広範囲ですが、特定の特徴があり、それにより検出が容易です。例には、Golangのマップの反復処理に関する問題やRustのパニックメカニズムなどがあります。これらの言語固有のリスク要因をリストアップし、使用または監査中にこれらに特に注意して、このようなエラーを最小限に抑えることをお勧めします。

サマリー

Cosmosエコシステムにおける基本的なセキュリティ問題の調査から、これらの問題はCosmosに固有のものではなく、他のブロックチェーンエコシステムにも適用可能であることが明らかになりました。以下は、Cosmosエコシステムにおけるセキュリティ問題に関するいくつかの推奨事項と結論です。

• インフラストラクチャの脆弱性に注意してください：CometBFTやCosmos SDKなどのコアコンポーネントにも脆弱性がある可能性がありますので、セキュリティのためには定期的な更新とメンテナンスが必要です。

• 第三者のライブラリを迅速にレビューしてください：Cosmosの開発者は、アプリケーションの機能を拡張するために頻繁にサードパーティのライブラリを使用します。これらのライブラリには潜在的な脆弱性が含まれている可能性があり、そのためレビューと更新が必要です。

• 悪意のあるノード攻撃に注意してください：コンセンサスノードはCosmosエコシステムで重要です。これらのノードのビザンチン障害耐性アルゴリズムは攻撃の影響を受ける可能性がありますので、ノードのセキュリティを確保して悪意のある行動を防ぐことが重要です。

• 物理セキュリティを考慮してください：Cosmosノードを実行するハードウェアとサーバーの物理セキュリティ対策が必要です。これにより、不正アクセスや潜在的な攻撃を防止できます。

• 必要なコードレビューを実施します。Cosmos SDKとCometBFTエコシステムのオープン性を考慮すると、開発者や監査者は、潜在的なセキュリティ問題を特定し修正するために、コアコードとカスタムモジュールで書かれたコードの両方をレビューすべきです。

• エコシステムツールに注意してください：Cosmosエコシステムには多くのツールやアプリケーションが含まれており、それらもセキュリティレビューや定期的な更新を受ける必要があります。これによって安全性が確保されます。

IBCプロトコルセキュリティガイド

このモジュールは、Cosmosエコシステムにおける重要なコンポーネントであるInter-Blockchain Communication（IBC）プロトコルのセキュリティに焦点を当てています。IBCプロトコルは、異なるブロックチェーン間の相互作用のための橋渡しとして機能します。他のクロスチェーンブリッジが特定の孤立した問題に対するソリューションを提供する一方で、IBCプロトコルは異なるチェーン間の相互作用のための統一された基礎的なソリューションと基盤となる技術サポートを提供します。IBCは、異種ブロックチェーンが信頼性の高い、整然とした、最小限の信頼を要する方法で任意のデータを転送することを可能にするプロトコルです。

Bitcoinの登場以来、ブロックチェーン分野は爆発的な成長を遂げてきました。数え切れないほどの新しいネットワークが現れ、それぞれが独自の価値提案、コンセンサスメカニズム、イデオロギー、支持者、存在理由を持っています。IBCの導入前、これらのブロックチェーンは閉じられた容器のように独立して運営され、お互いに通信することができませんでした。それは根本的に持続不能なモデルでした。

もしブロックチェーンが成長する人口や活気ある商業活動を持つ国と見なされるなら、一部は農業に優れ、他の国は畜産に秀でています。当然ながら、それぞれが持つ強みを活かし合い、互恵的な貿易と協力を求めることになります。IBCが新たな無限の可能性を開き、異なるブロックチェーン同士が相互運用し、価値を転送し、資産やサービスを交換し、そして今日の大規模なブロックチェーンネットワークの固有のスケーラビリティの問題に阻まれることなく接続を確立することができると言っても過言ではありません。

では、IBCはこれらのニーズをどのように満たし、なぜそのような重要な役割を果たすのでしょうか？その根本的な理由は、IBCが以下の通りであることです:

1. 信頼の最小化

2. 異種のブロックチェーンをサポートできる

3. アプリケーションレイヤーでカスタマイズ可能

4. 成熟した、テスト済みのテクノロジー

IBCプロトコルの基盤は、軽量クライアントと中継者にあります。IBCを介して通信するチェーンAとBは、それぞれ他方の台帳の軽量クライアントを所有しています。サードパーティを信頼する必要がないチェーンAは、ブロックヘッダーを検証することで、チェーンBの状態について合意に達することができます。IBCを介して相互作用するチェーン（特にモジュール）は、直接メッセージを互いに送信しません。代わりに、チェーンAは、データパケットの特定のメッセージをその状態に同期させます。その後、中継者はこれらのデータパケットを検出し、ターゲットチェーンに転送します。

全体的に、IBCプロトコルは、IBC TAOとIBC APPの2つのレイヤーに分かれることができます。

• IBC TAO: データパケットの転送、認証、および順序付けの標準を定義し、基本的にはインフラストラクチャレイヤーを構成します。ICS（インターチェーンスタンダード）では、これにはコア、クライアント、リレーカテゴリが含まれています。

• IBC APP: Defines the standards for application handlers of data packets transmitted through the transport layer. These include, but are not limited to, fungible token transfers (ICS-20), non-fungible token transfers (ICS-721), and interchain accounts (ICS-27), and can be found in the application category of ICS.

IBCプロトコル（Cosmos Developer Portalより）

IBC（Inter-Blockchain Communication）プロトコルは、Cosmosエコシステムの「ブロックチェーンのインターネット」というビジョンの基幹です。この文脈において、IBCの設計はTCP/IP標準に影響を受けています。TCP/IPがコンピュータ間の通信の標準を設定するのと同様に、IBCはブロックチェーン間の通信を可能にする一連の普遍的な抽象化を指定しています。TCP/IPがネットワークを介して中継されるデータパケットの内容を制限しないように、IBCも同様に動作します。さらに、HTTPやSMTPなどのアプリケーションプロトコルがTCP/IPの上に構築されているのと同様に、均質化された資産/非代替資産の転送やクロスチェーンスマートコントラクト呼び出しなどのアプリケーションもIBCプロトコルを基盤として利用しています。

IBCプロトコルに現在見られる主な問題は、チャネルの伝送とパケット処理に関連しています。証明検証に関する重大な問題がありましたが、これらは比較的一般的ではありません。この記事はIBCプロトコルの一般的な問題に焦点を当てています。IBCプロトコルのモジュラーデザインのおかげで、IBCアプリケーション開発者はクライアント、接続、証明検証などの基本的な詳細について心配する必要はありません。ただし、IBCModuleインターフェースと対応するKeeper処理メソッドを実装する必要があります。そのため、IBCプロトコルに関連する多くの問題は、パケットの受信と処理のためのIBCModuleインターフェースのコードパスで発生します（onRecvPacket、OnAcknowledgementPacket、OnTimeoutPacketなど）。

一般的な脆弱性分類

コスモスエコシステムでは、IBCプロトコルが接続ハブとして機能します。IBCプロトコルに関連する脆弱性の種類は多岐にわたり、Cosmos-SDKやCometBFTなどのモジュールとの緊密な統合により複雑です。さらに、IBCは主にCosmosエコシステムで使用されるため、その主要なプログラミング言語はibc-goのドキュメントに詳細に記載されているようにGolangです。

スペースの制約により、この記事はIBCプロトコルのすべての側面とコンポーネントの詳細な分析には踏み込んでいません。代わりに、既存のセキュリティ脆弱性のいくつかを分類しています。詳細で包括的な分析については、お気軽に当社のCertiKセキュリティエンジニアにご連絡ください。

Common Vulnerability Classifications:

1. ネーミングの脆弱性

   ① 文字列処理の脆弱性

   ② バイトコード処理の脆弱性

2. Transmission Process Vulnerabilities

   ① パケット注文の脆弱性

   ② パケットタイムアウトの脆弱性

   ③ パケット認証の脆弱性

   ④ その他のパケット脆弱性

3. 論理的な脆弱性

   ① 状態の更新の脆弱性

   ② 投票およびコンセンサスの脆弱性

   ③ その他の論理的な脆弱性

4. ガス消費の脆弱性

既存のIBCプロトコルは、監査およびセキュリティの分析の観点から、Web2プロトコルの監査プロセスと多くの類似点を共有しています。この分析では、IBCプロトコルのセキュリティの問題や潜在的なリスクの一部を、プロトコルの確立、実装、およびアプリケーション拡張の観点から解析します。プロトコルの策定はしばしばわずかな個人や組織によって完了されるため、さまざまなブロックチェーン組織にとって、より多くの作業がプロトコルの実装とアプリケーションの拡張にかかわります。したがって、この記事では、これらの側面のセキュリティの問題に焦点を当てます。このアプローチは、IBCプロトコルによってカバーされる幅広いセキュリティリスクの考慮から生じており、異なるタイプのセキュリティの問題を対応する段階やモジュールによりよく分類できるようにしています。

脆弱性分析

IBCプロトコルの策定

ケーススタディ1：ICS-07プロトコル、論理的脆弱性

脆弱性の背景：Unbinding期間の誤った使用

コードには、次の検証が存在します:

if currentTimestamp.Sub(consState.Timestamp) >= clientState.UnbondingPeriod

Tendermintセキュリティモデルによると、時刻tでのブロック(ヘッダー)に対して、NextValidators内の検証者はt+TrustingPeriodより前に正しく動作する必要があります。その後、他の振る舞いを示す可能性があります。ただし、ここでの確認はTrustingPeriodではなく、UnbondingPeriodのため、UnbondingPeriod > TrustingPeriodです。 consStateの締め切りがTrustingPeriodとUnbondingPeriodの間にある場合、このヘッダーは不正行為を構成する競合するヘッダーの1つを検証するための基準として受け入れられます。この期間中、consState.NextValidatorsの検証者はもはや信頼できるとは見なされず、敵対的な元の検証者はクライアントをリスクなしでシャットダウンできます。

プロジェクトアドレス: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-007-tendermint-client

脆弱性の場所:

• https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-007-tendermint-client#misbehaviour-predicate

• https://github.com/cosmos/cosmos-sdk/blob/6344d626db1fbdba5e0f67425703c1584021bf5b/x/ibc/light-clients/07-tendermint/types/misbehaviour_handle.go#L96

脆弱なコードスニペット：

プロトコル定義機能

コード

IBCプロトコルの実装

IBCプロトコルの実装段階は、重要な橋渡しの役割を果たすため、問題が発生しやすい段階です。プロトコル仕様での曖昧さを避けるだけでなく、後続のプロトコルの応用と拡張のための基本的で便利なインタフェースを提供する必要があります。したがって、IBCプロトコルの実装段階での主な問題はさらに以下のようにカテゴリ分けされます：

1. プロトコルの実装における曖昧さや非標準的な問題。

2. プロトコル設定のエラー。

プロトコル実装における曖昧さと非標準的な問題

ケーススタディ1：ICS-20プロトコル、ネーミング脆弱性

Vulnerability Background: Custodial address conflict. The GetEscrowAddress()function generates a 20-byte truncated SHA256 (Port ID + Channel ID). This method has three issues:

1. ポートとチャネルの間のドメイン分離の不足。文字列連結メソッドは、ポートとチャネルのドメインを分離しません。たとえば、ポート/チャネルの組み合わせ（“transfer”、“channel”）と（“trans”、“ferchannel”）は、同じカストディアルアドレス、つまり切り捨てられたSHA256（“transferchannel”）に結果が出ます。特定のライブラリ関数を持つモジュールがポートおよびチャネルIDを選択することを許可されると、脆弱性が発生する可能性があります。

2. モジュールアカウントアドレス間の競合があります。 SHA-256のプレイイメージには、任意の英数字文字列が使用され、ポストイメージのサイズは160ビットです。この小さなポストイメージは高速ハッシュ関数と組み合わされ、そのセキュリティは80ビットにのみ低下しており、誕生日攻撃が実現可能です。これは、異なる管理アカウントアドレス間で衝突を見つけるには、約2^80の推測が必要であることを意味します。 2018年、TendermintのコンテキストでSHA256の切り詰め攻撃の詳細なコスト分析が実施され、このような攻撃がコストの観点から実現可能であることが証明されました。 衝突を見つけることは、2つの異なる管理アカウントが同じアカウントアドレスにマップされていることを意味します。 これにより、管理アカウントから資金が盗まれるリスクが発生する可能性があります。詳細については、ICS20 GetEscrowAddressプレイイメージドメインが公開鍵と重複していることを参照してくださいT：BUG。

3. モジュールと非モジュールアカウントアドレスの間の衝突。公開アカウントアドレスの構築は、20バイトのSHA-256のEd25519公開鍵と同じです。特定の公開アドレスへの衝突攻撃を防ぐには160ビットのセキュリティが十分ですが、誕生日攻撃に対するセキュリティは80ビットしかありません。この状況は、半誕生日攻撃モードに似ており、1つのアドレスは高速なSHA-256によって生成され、他のアドレスは比較的遅いEd25519公開鍵の計算によって生成されます。この状況はより安全ですが、預託および公開アカウントへの潜在的な攻撃を引き起こす可能性がまだあります。

プロジェクトアドレス：https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-020-fungible-token-transfer

脆弱性の位置: https://github.com/cosmos/cosmos-sdk/blob/6cbbe0d4ef90f886dfc356979b89979ddfcd00d8/x/ibc/applications/transfer/types/keys.go#L40-L47

https://github.com/cosmos/cosmos-sdk/blob/6cbbe0d4ef90f886dfc356979b89979ddfcd00d8/x/ibc/applications/transfer/keeper/relay.go

脆弱なコードスニペット：

プロトコル設定エラー問題

• Case 1: IBCセキュリティアドバイザリーDragonberry、送信プロセスの脆弱性

脆弱性の背景：IBCは、アプリケーションデータパケットを処理する際にパケット構造を使用します。タイムアウトメカニズム、同期および非同期確認メカニズム、および対応する認証検証プロセスに従い、データパケットは2つの実行プロセスに分割されます。

1. 通常の状況：タイムアウト内に成功

2. タイムアウト状況：タイムアウトの失敗

IBCアプリケーションパケット送信フローチャート

タイムアウトが発生すると、送信が失敗したことを意味し、IBCプロトコルが返金プロセスを開始します。IBCには、ユーザーが設定可能なタイムアウトメカニズムがあることに注意してください。Dragonberry の脆弱性は ICS-23 (IBC) に起因します。この脆弱性の根本的な原因は、ユーザが検証プロセスにおいて存在しない証拠(すなわち、データパケットが受信されていないという偽の証明)を偽造し、セキュリティチェックを迂回し、偽造する「妥当な」IBCタイムアウト状況が、IBCプロトコルを欺くために使用され、リピータに偽の証明書でタイムアウトパケットを送信させる、 ICS-20の二重支出問題にエスカレートする可能性があります。この脆弱性の具体的な引き金となるプロセスは、下図のとおりです。

ドラゴンベリー脆弱性原則フローチャート

プロジェクトアドレス: https://github.com/cosmos/ibc-go/tree/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel

脆弱性の位置: https://github.com/cosmos/ibc-go/blob/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel/keeper/timeout.go#L117C28-L117C54

Vulnerable code snippet:

• Case 2: IBCセキュリティアドバイザリーハックルベリー、転送プロセスの脆弱性

脆弱性の背景: UnreceivedPacketsは、クエリに含まれる各シーケンス番号に対応するパケット受信レシートを見つけることでのみ応答を構築します。これは、順序付けられたチャネルではなく、パケット受信の代わりにnextSequenceRecvを使用するため、順序付けられたチャネルでは機能しません。そのため、順序付けられたチャネルでは、GetPacketReceiptを介してシーケンス番号をクエリすると、その中にレシートが見つからないでしょう。

この問題の深刻度は小さいです。なぜなら、ICS-20 FTによって送信されるチャネルはほとんど正常ではなく、リピーターはこのgrpcエンドポイントに依存してタイムアウトをトリガーするパケットを決定しません。ただし、対象チェーンに多数のパケットが存在し、順序付けられたチャネルがIBC伝送用に構成されており、grpc応答がページ分割されていない場合、これによりサービスノードのパフォーマンスが低下したり、クラッシュしたりするリスクが発生します。具体的なトリガリングプロセスは、以下の図で確認できます。

Huckleberry脆弱性原則フローチャート

プロジェクトアドレス: https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-channel/

脆弱性の位置: https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-channel/keeper/grpc_query.go#L408

脆弱なコードスニペット：

IBCプロトコルの適用と拡張

• ケース1：ストライドエアドロップ脆弱性、ロジック脆弱性

Vulnerability Background: The function TryUpdateAirdropClaimIBCパケットの送信元アドレスをStrideアドレスに変換しますsenderStrideAddress, そして抽出しますairdropIdそして新しいエアドロップアドレスnewStrideAddressパケットメタデータから。 次に、それを呼び出しますUpdateAirdropAddress更新するsenderStrideAddressそしてClaimRecord. 更新とともに請求レコード, newStrideAddressエアドロップを請求できるようになります。ただし、この更新関数は、要求の送信者アドレスが空であるかどうかを検証するだけで、検証は行いませんnewStrideAddress.IBCでは、ソロマシン接続でIBC対応チェーンを実装できるため、他のアカウントアドレスをエアドロップアドレスとして更新できるセキュリティリスクがあります。

プロジェクトアドレス：https://github.com/Stride-Labs/stride/tree/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot

脆弱性の位置: https://github.com/Stride-Labs/stride/blob/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot/module_ibc.go#L119

https://github.com/Stride-Labs/stride/blob/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot/keeper/airdrop.go#L17

脆弱なコードスニペット:

• Case 2: neutron ibc module vulnerability, gas consumption vulnerability

脆弱性の背景:スマートコントラクトのコンテキストでは、IBC(Inter-Blockchain Communication)イベントの確認またはタイムアウトに対する手数料の検証方法に問題があります。この欠陥により、悪意のあるスマートコントラクトが「ErrorOutOfGas」クラッシュを引き起こす可能性があります。このクラッシュは、「OnAcknowledgementPacket」および「OnTimeoutPacket」メッセージの処理中に発生します。このエラーが発生した場合、通常の「outOfGasRecovery」メソッドでは解決できません。その結果、影響を受けるトランザクションはブロックチェーンブロックに含まれません。この障害により、IBC リレーはこれらのメッセージの送信を繰り返し試行する可能性があります。このような繰り返しの送信は、リレイヤーの経済的損失につながり、過剰な数の未処理(「放棄」)パケットでネットワークに過負荷をかけ、ネットワークの安定性にリスクをもたらす可能性があります。

プロジェクトアドレス：https://github.com/neutron-org/neutron/blob/64868908b21f648ad5e8a9b48179134619544e2a/

脆弱性の位置:

https://github.com/neutron-org/neutron/blob/64868908b21f648ad5e8a9b48179134619544e2a/x/interchaintxs/keeper/ibc_handlers.go#L62

脆弱なコードスニペット：

概要

前のテキストで提示された、Inter-Blockchain Communication（IBC）プロトコルに関連するセキュリティ問題の分析と議論は、これらの懸念の普及と多様性を浮き彫りにしています。主な課題は、実装段階とIBCプロトコルを利用するアプリケーションの拡大から主に発生するようです。さまざまなアプリケーションチェーンが徐々に伝統的なモジュール機能を向上し洗練化する一方で、IBCモジュールにさまざまなコード実装を組み込んでいます。これは、パフォーマンスを向上させ特定のビジネス要件に対応するために行われています。

IBCコンポーネントで既に言及されたセキュリティの問題に加えて、新たな課題が特にIBCミドルウェアで表面化しています。これらの進化する懸念事項は、将来的には特にCosmosエコシステム全体のセキュリティに関する重要性が増していくと予想されています。この変化は、IBCモジュールの堅牢なセキュリティ対策の確保への重点が高まっていることを示しています。

結論

Cosmosエコシステムのセキュリティに関する調査は、詳細な監査、要約、および分類を含むものであり、その中心はCosmos SDKおよびIBCプロトコルという2つの最も重要なコンポーネントにあります。私たちの豊富な実践的経験に基づいて、一般的な監査の専門知識を包括的にまとめました。

このレポートは、特にクロスチェーンの相互作用をサポートするCosmosのような異種ネットワークがもたらす独自の課題を強調しています。そのコンポーネントの複雑さと分散性は、それらのセキュリティを確保する課題を非常に困難なものにしています。セキュリティリスクに関する既存の知識を適用するだけでなく、新たなセキュリティシナリオに適応して新興の問題に対処する必要があります。

これらのハードルにもかかわらず、私たちは楽観的です。このレポートで行っているように、一般的なシナリオやセキュリティの課題を文書化し分析することで、Cosmosエコシステム全体のセキュリティフレームワークを着実に向上させる道を切り拓いています。

免責事項：

1. この記事は[から転載されましたCertiK(サーティク)]. すべての著作権は元の著者に帰属します [CertiK].この転載に異議がある場合は、Gate Learnチーム、そして彼らはそれを迅速に処理します。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 他の言語への記事の翻訳は、Gate Learnチームによって行われます。特に記載がない限り、翻訳された記事のコピー、配布、あるいは盗用は禁止されています。