ログイン/ 登録

CertiK：コスモスのエコ・セキュリティを解体し、Web3の星への旅を支援する

2023/12/27 12:56

従う

出典:CertiK

先週、CertiKチームが公開したコスモス・エコ・セキュリティ・ガイドが、Web3メディアMeta Eraが初公開され、多くのメディアによって再投稿され、Web3コミュニティから広く注目を集めました。

世界最大かつ最も有名なブロックチェーンエコシステムの1つとして、Cosmosはブロックチェーンの相互運用性を向上させ、異なるブロックチェーン間の効率的な相互運用性を実現することに注力しています。CelestiaとdYdX v4を含む一連の主要プロジェクトは、Cosmos SDKとIBCプロトコルに基づいて構築されています。

Cosmosの開発コンポーネントがより多くの開発者に支持されるにつれて、Cosmosのエコシステムにおけるセキュリティ問題は、より広い範囲に影響を及ぼすことになるでしょう。たとえば、Cosmos SDKの以前のDragonfruit脆弱性は、いくつかの主流のパブリックチェーンの正常な動作に影響を与えました。Cosmosエコシステムの基本コンポーネントは分散化されているため、開発者は異なる機能要件に応じて異なるコンポーネントを使用または拡張する必要があり、その結果、Cosmosエコシステムのセキュリティ問題は分散化され、多様な性質を持つことになる。開発者がCosmosエコシステムのセキュリティと対応オプションの現状を構造的に理解するための研究も必要です。

CertiKチームは「Cosmosエコシステムセキュリティガイド」を独占的にリリースしました。このガイドでは、Cosmosエコシステムのさまざまなコンポーネントのセキュリティシナリオを、読者にわかりやすいカテゴリを通して綿密に分析しています。このレポートには、Cosmosエコシステムにおける過去の主要なセキュリティ脆弱性の分析が含まれているだけでなく、原因、結果、コードの場所などに基づいて、一般的なセキュリティ脆弱性のいくつかを分類しています。これは、Cosmosエコシステムの開発者のためのセキュリティガイドラインを最大化し、Cosmosセキュリティ問題の学習と監査のためのインデックス化された情報をセキュリティ監査人に提供します。

CertiKチームは、継続的な調査とマイニングを通じて、CosmosとWeb3エコシステム全体のセキュリティ向上を支援してきました。私たちは、定期的にあらゆる種類のプロジェクトセキュリティレポートと技術研究をお届けします！ご不明な点がございましたら、お気軽にお問い合わせください。

以下は「コスモス・エコセキュリティ・ガイド」の全文です。

コスモス・エコセキュリティ・ガイド

概要

コスモスは、オープンソースで、オープンで、拡張性の高いブロックチェーンのクロスチェーンネットワークであり、世界で最も有名なブロックチェーンエコシステムの1つです。Cosmosは、CometBFT（旧Tendermintチーム）がクロスチェーン交流をサポートするために立ち上げた異種ネットワークで、複数の独立した並列ブロックチェーンで構成され、分散型ネットワークを形成しています。そのビジョンは、情報のサイロ効果を打破し、異なるブロックチェーン間の相互運用性を実現することです。現在のマルチチェーン時代において、クロスチェーン相互作用の実現はブロックチェーン業界にとって急務となっている。

Cosmosは効率的なクロスチェーンモデルを提供しており、特に特定の業種に特化したパブリックチェーンに適しています。モジュール式のブロックチェーンインフラストラクチャを提供することで、Cosmosはさまざまなアプリケーション開発者がニーズに合ったパブリックチェーンを選択して使用できるようにします。

Cosmosエコシステム内のアプリケーションとプロトコルは、IBC (Interblockchain Communication Protocol)を使用して接続され、個々のブロックチェーン間のクロスチェーン相互作用を可能にし、資産とデータの流れを自由にします。
Cosmosのビジョンは、多数の自律的で開発しやすいブロックチェーン間の拡張と相互作用の可能性を提供するブロックチェーンのインターネットを構築することです。

以前からコスモスは、ブロックチェーンのインターネットを構築してきました。

CertiKは長い間、Cosmosエコシステムに注目し、研究を続けてきました。Cosmosエコシステムのセキュリティ問題について十分な経験を蓄積してきました。この研究報告書では、Cosmosエコシステムのセキュリティについて、主にCosmos SDKのセキュリティ、IBCプロトコルのセキュリティ、CometBFTのセキュリティ、CosmWasmのセキュリティという4つの方向性に焦点を当てた探求と研究結果を紹介します。

Cosmosエコシステムは複雑で多様であり、セキュリティ問題も多様であるため、この研究はすべての種類のセキュリティ脆弱性を網羅しているわけではなく、Cosmosエコシステムにとってより有害な、より典型的な脆弱性のみを調査しています。その他のセキュリティ問題の詳細については、CertiKセキュリティエンジニアにお問い合わせください。

背景

CometBFT：クロスチェーンのスケーラビリティの礎石

CometBFTは、次の2つで構成される革新的なコンセンサスアルゴリズムです。革新的なコンセンサスアルゴリズムであり、基盤となるコンセンサスエンジン（CometBFT Core）と共通アプリケーションブロックチェーンインターフェース（ABCI）の2つの主要コンポーネントで構成されています。そのコンセンサスアルゴリズムは、ハイブリッドPBFT+ボンドPoSコンセンサスを使用し、ノードが同期してトランザクションを記録することを保証します。Interchainのスケーラビリティの中核をなすCometBFTは、バリデータ・コンセンサスを通じてInterchainエコシステムのセキュリティ、分散化、完全性を維持します。

Cosmos SDK：モジュール性と新機能

CosmosSDKは、開発者が開発プロセスを加速するためのツールキットです。

CosmosSDKは、モジュール性とプラグイン性を提供することで、開発者の開発プロセスを加速させるツールキットです。 Cosmos SDKを使用することで、開発者は独自のブロックチェーンやCometBFTコンセンサスアルゴリズムに基づく機能コンポーネントを構築することができ、便利な開発と開発サイクルの短縮を可能にします。今後の開発計画では、開発者がより複雑でモジュール化されたアプリを作成できるようにするモジュール性と新機能の導入に重点を置き、より広範で堅牢なエコシステムを育成する予定です。

IBC Protocol: Enhanced Interoperability and Scalability

IBC protocol (Inter-Blockchain Communication)は、ブロックチェーン間の安全で分散化された許可なしのデータ転送を可能にします。ブロックチェーン間の中央集権的で許可なしのデータ転送。Cosmosは独立した並列ブロックチェーンの分散型ネットワークであり、異なるブロックチェーン間のクロスチェイニングを可能にするためにリレー技術を使用しているため、IBCは間違いなくプロジェクトの最も中心的な部分である。IBCのスケーラビリティと相互運用性を高めることで、Cosmosはブロックチェーン、アプリ、スマートコントラクト間のシームレスな相互作用を可能にするエコシステムの能力をさらに高めるだろう。

CosmWasm: Unlocking Decentralised, License-Free Deployment

CosmWasm (Cosmos WebAssembly) は、WebAssemblyベースのスマートコントラクトです。)は、Cosmosエコシステム用に設計されたWebAssemblyベースのスマートコントラクトフレームワークです。開発者はライセンス要件なしに分散型アプリケーションをデプロイすることができ、またブロックチェーン開発者は製品開発サイクルをブロックチェーン開発から切り離すことができるため、バリデータのアップグレードにかかるコストを削減することができます。これに加えて、モジュラーアーキテクチャ、Cosmos SDKの統合、クロスチェーン通信などを特徴としています。

今日現在、Cosmos SDK、IBCプロトコルは比較的成熟しており、現在のCosmosエコシステムで最も広く使用されています。

チェーン開発者の視点から見ると、Cosmosエコシステムで必要とされるカスタマイズのほとんどは、Cosmos SDKに依存することで実現できますが、クロスチェーン操作の過程でいくつかの特別な操作を実現するため、またはパフォーマンスを最適化する目的で、チェーン開発者は独自のIBCモジュールをカスタマイズします。さらに、少数のチェーンは、CometBFT Coreのような基礎となるエンジンを変更し、カスタマイズしますが、これはスペースの制限のため、この調査報告書では説明しません。この調査報告書は、Cosmos SDKとIBCプロトコルの技術的なポイントとセキュリティ問題の分析に焦点を当てます。

Cosmos SDKセキュリティガイド

Cosmos SDKは、ブロックチェーンアプリケーションと分散型プロトコルを構築するための強力で柔軟なフレームワークです。これはInterchain Foundationによって開発され、相互接続されたブロックチェーンの分散型ネットワークであるCosmos Networkのコアコンポーネントです。

Cosmos SDKは、カスタムブロックチェーンアプリケーションの開発を簡素化し、異なるブロックチェーン間のシームレスな相互運用性を可能にするように設計されています。Cosmos SDKには、次のような主な特徴があります：モジュール型アーキテクチャ、カスタマイズ可能性、CometBFTベース、IBCコレスポンデントインターフェースの実装、開発者に優しい。CosmosのSDKは、CometBFTコアのコンセンサスエンジンを活用することで、悪意のある攻撃からネットワークを保護し、ユーザーの資産とデータを保護します。また、モジュール化されているため、ユーザーは簡単にカスタムモジュールを設計することができます。これらの利点にもかかわらず、開発者がCosmos SDKを使用して独自のアプリケーションを実装する場合、セキュリティの脆弱性が存在する可能性があります。

セキュリティ監査の観点からは、監査目的を徹底し、セキュリティリスクをあらゆる角度から検討する必要がありますが、セキュリティ研究の観点からは、重大な影響を及ぼしうるセキュリティ脆弱性に焦点を当て、短期間で最大のセキュリティリスクをできるだけ回避し、統合サービスプロバイダにより効果的な支援を提供する必要があります。この観点から、リスクが高く、影響が大きい脆弱性について脆弱性モデルを分類し、分析することは、非常に必要で価値のある作業です。

Cosmosエコシステム全体のABCIインターフェースの中で、私たちは4つのインターフェースBeginBlock、EndBlock、CheckTx、およびDeliverTxに焦点を当てます。最初の2つは単一のブロックの実行ロジックに直接関連し、後の2つはsdk.Msg（メッセージを送信するためのCosmosエコシステムの基盤）の特定の処理に関連します。データ構造を送信するためのCosmosエコシステムの基盤)固有の処理に関連しています。

Cosmosエコシステム上のさまざまなアプリケーションチェーンの実装ロジックは、Cosmos SDKと同様のモジュールとサンプルに従うことができるため、以下のセキュリティ脆弱性を分析し理解するには、Cosmos SDKのモジュールランタイムフローの基本的な概念が必要です。

Cosmosエコシステムでは、トランザクションは最初にユーザーエージェントで作成され、その後署名されてブロックチェーン内のノードにブロードキャストされます。ノードはCheckTxメソッドを利用して、署名、送信者の残高、トランザクションシーケンス、提供された燃料など、さまざまなトランザクションの詳細を検証します。トランザクションが検証に合格すると、ブロックに含まれるのを待っているメモリプールに追加される。あるいは、トランザクションが検証に合格しなかった場合、エラーメッセージがユーザーに送られ、トランザクションは拒否される。ブロックの実行中、トランザクションに対して更なるチェックが行われ、これは一貫性と確実性を保証するためにDeliverTxメソッドを通して行われる。

Cosmos SDKでは、トランザクションのライフサイクルは以下のフローとして簡単に説明できます。

1.トランザクションの作成：トランザクションは、さまざまなツール、CLI、またはフロントエンドを使用して、クライアントサイドで作成されます。

2.メモリプールへの追加: トランザクションはメモリプールに追加され、ノードがABCIメッセージ-CheckTxをアプリケーションレイヤに送信して有効性をチェックし、結果abci.ResponseCheckTxを受け取ります。ValidateBasic()がTxの各sdk.Msgで呼び出され、最初のステートレス有効性チェックが実行される。対応するanteHandlerがアプリケーションに存在する場合、まずその内部ロジックを実行し、次にrunTx関数を呼び出します。runTx関数は最終的にRunMsgs()関数を呼び出し、sdk.Msgの特定のコンテンツを処理します。CheckTxが成功すると、メッセージは次のブロックの候補としてローカルメモリプールに追加され、P2P経由でピアPeerノードにブロードキャストされる。

3. Contained in a Proposal Block:各ラウンドの最初に、提案者は最新のトランザクションを含むブロックを作成し、最後にノード全体のコンセンサスを担うバリデータがブロックを受け入れるか、空のブロックに投票することに同意します。

4.状態変更: DeliverTxは、CheckTxと同様にブロック内のトランザクションを繰り返し実行するために呼び出されるが、DeliverモードでrunTxを呼び出し、状態変更を実行する。その後、MsgServiceRouterが呼び出され、Msg Serverで対応する各メッセージを実行する。その後、メッセージの実行後にチェックが実行され、失敗があれば状態が復元される。実行中、燃料（ガス）の使用量を記録するためにガス・メーターが使用される。燃料エラーが発生した場合（燃料が足りないなど）、実行失敗後と同じ結果で状態変更が元に戻されます。

5. ブロックの提出：ノードが十分なベリファイア票を受け取ると、ブロックチェーンに追加される新しいブロックを提出し、アプリケーション層の状態遷移を確定します。

エコシステム上のコスモス。トランザクションライフサイクル図

以下はCosmos SDKの具体的な実行ロジックで、以下の脆弱性トリガーパスを分析する際に簡単にアクセスし、理解することができます:

ABCIに焦点を当てたCosmos SDKの具体的な実行ロジック

一般的な脆弱性の分類

脆弱性の分類を理解する前に、脆弱性の危険性の基本的な分類を持つ必要があります。

危険の度合いと影響の範囲を考慮すると、私たちはクリティカル（Critical）およびメジャー（Major）評価のセキュリティ脆弱性に焦点を当てます。

1.チェーンの停止

2.資金の損失

3.システムの状態または正常な動作への影響

そして、これらの危険は、多くの場合、次のようなタイプのセキュリティ脆弱性によって引き起こされます:

1.サービス拒否

2.不正な状態設定

3.認証の欠落またはあり得ない認証

4.一意性の問題

5.コンセンサスアルゴリズムの問題

6.実装におけるロジックホール

7.言語機能

脆弱性分析

Cosmosのエコモジュール性により、あらゆる種類のチェーン実装において、モジュール間の使用やモジュール内の呼び出しが多く存在します。

Cosmosエコシステムのモジュール性により、モジュール間およびモジュール内呼び出しが多数存在するため、脆弱性トリガー経路と脆弱性トリガー位置変数制御可能経路が矛盾しており、脆弱性トリガーを分析する際、トリガー経路に注目するだけでなく、脆弱性キー変数制御可能経路にも注意を払う必要があり、脆弱性モデルの定義をより明確にするのに役立ちます。

チェーン停止

チェーン停止は、個々のブロック実行の問題によって引き起こされることがほとんどですが、Cosmosの歴史の中でも、チェーン停止につながるコンセンサスセキュリティの脆弱性がありました。しかし、Cosmosの歴史の中で、それを修正するためにチェーンを自発的に停止させなければならないようなコンセンサス型のセキュリティ違反もありました。そこで、ここでは、チェーンを停止させるコンセンサス型のセキュリティ違反の影響について説明し、これら2種類の問題についてそれぞれ別々にお話しします。

最初のタイプの状況は、一般的にサービス拒否タイプの脆弱性で、不適切なクラッシュ処理や、ユーザーが影響を受ける可能性のあるループ境界のトラバーサルによって引き起こされます。このタイプの脆弱性は、チェーンが一時停止したり、動作が遅くなるなどの原因になりがちです。

前節で述べたように、Cosmos SDKとCometBFTは、Cosmosエコシステムの重要なインフラストラクチャとして、Cosmosの基本的なチェーンによって使用されるだけでなく、あらゆる種類のアプリケーションチェーンによって、そのアーキテクチャに基づいて独自のロジックを実装するために使用されるため、それらはすべてCometBFTのABCIインターフェイス規則に従っており、攻撃対象領域の焦点はABCIインターフェイスにあります。であり、チェインハルトのセキュリティ脆弱性のほとんどは、ブロックコードの実行に直接影響する問題であるため、その経路は基本的にBeginBlockとEndBlockインターフェイスにたどることができます。

2つ目のタイプの脆弱性は、コンセンサスに影響を与えるもので、通常、さまざまなタイプのチェーンの実装に関連しており、現在、いくつかのロジック処理の検証、時間の較正、ランダム性の問題でよく知られています。このタイプの脆弱性は、本質的にブロックチェーンの分散化原則に影響します。直感的にはあまり影響がないように見えるかもしれませんが、それでも、善意の誰かによって悪意を持って設計された場合、重大なセキュリティリスクをもたらす可能性があります。

最初のシナリオ

ケース1：SuperNova

脆弱性の背景：鋳造配布作業におけるアドレス検証の欠如。コインの鋳造分配操作におけるアドレス検証の欠如は、操作の失敗と資金の損失につながります。コイン鋳造モジュールでは、各トークンの鋳造は担保額に依存する。しかし、プールが存在しなかったり、契約アドレスが誤って入力されたりすると、造幣モジュールで予期せぬ事態が発生し、ブロックチェーンの動作が停止する可能性がある。報酬プールモジュールでは、プール契約アドレスは検証されない。分配操作に失敗すると、チェーンは単に停止します。

脆弱性の場所: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/mint/keeper/keeper.go#L175

脆弱性のコードスニペット:

脆弱性トリガーパス:

BeginBlocker (/x/mint/keeper/abci.go)      Keeper.DistributeMintedCoin (/x/mint/keeper/abci.go)nbsp;   PoolIncentiveKeeper.GetAllIncentivePool (/x/mint/keeper/keeper.go)

脆弱性パッチ：

パッチはpoolincentiveのメッセージ処理モジュール(/x/poolincentive/types/msgs.go)にあります。/types/msgs.go)にあります。

MsgCreateCandidatePoolを処理する(つまり、プールを作成する)メッセージでアドレスチェックサムを行うことは、ルートで間違ったアドレスが発生する可能性を排除する試みです。

Case 2: Cosmos Interchain Security project

Project address: https://github.com/cosmos/interchain-security

脆弱性の背景: 認証者は、同じブロックで複数のAssignConsumerKeyメッセージを送信することで、プロビジョニングチェーンを遅くすることができます。x/ccv/provider/keeper/key_assignment.goで定義されているAssignConsumerKey関数は、認証者が承認されたコンシューマ・チェーンに異なるコンシューマ・キーを割り当てることを可能にする。AddressList を 1 つ増やす。この AddressList は、x/ccv/provider/keeper/relay.go の EndBlocker 内でトラバースされるため、攻撃者はこの AddressList を使用して、プロビジョニング・チェーンをスローダウンさせることができる。この攻撃を実行するには、悪意のあるアクターが複数の AssignConsumerKey メッセージでトランザクションを作成し、これらのトランザクションをプロバイダーチェーンに送信します。その結果、EndBlockerの実行に予想以上の時間とリソースがかかり、プロバイダー・チェーンの動作が遅くなるか、停止することさえあります。

脆弱性の場所： https://github.com/cosmos/interchain-security/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/provider/keeper/key_assignment.go#L378

Vulnerable code snippet:

脆弱性トリガーパス:

msgServer.AssignConsumerKey Keepを処理する。nbsp; HandleVSCMaturedPacket HandleLeadingVSCMaturedPackets 。(注) 1.このコマンドは、"pring "コマンドと呼ばれます。li>

脆弱性の背景: BeginBlockerとEndBlockerは、モジュール開発者がモジュールに実装できるオプションのメソッドです。これらはそれぞれ各ブロックの最初と最後にトリガーされます。EndBlockerは、モジュールが十分なトークンを持っているかどうかを考慮せずに未完成のエアドロップを清算するため、クラッシュの可能性を引き起こし、チェーンが機能しなくなります。

脆弱性の場所：https://github.com/quicksilver-zone/quicksilver/blob/b4aefa899e024d‍60f4047e2f2f403d67701b030e/x/airdrop/keeper/abci.go#L15

Vulnerability code snippet:

Vulnerability trigger path:

AppModule.EndBlock     Keeper.EndBlocker         Keeper.EndZoneDrop

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

パニック処理コードを直接削除し、ロギングエラーに置き換えました。

Case 4: Cosmos Interchain Security project

Project address: https://github.com/Cosmos/interchain-security

脆弱性の背景：攻撃者は、プロバイダーチェーンの報酬アドレスに複数のトークンを送信することで、サービス拒否攻撃を実現できます。

コンシューマチェーンのEndBlocker実行フローでは、x/ccv/consumer/keeper/distribution.goで定義されているSendRewardsToProvider関数が、tstProviderAddr内のすべてのトークンの残高を取得し、プロバイダチェーンに送信します。これを行うには、報酬アドレスで見つかったすべてのトークンを繰り返し処理し、IBC を介してプロバイダーチェーンに 1 つずつ送信する必要がある。誰でもトークンをリワード・アドレスに送信できるため、攻撃者は、トークン・ファクトリ・モジュールを持つチェーンなどを使って、異なる額面のトークンを大量に作成し、送信して、サービス拒否攻撃を仕掛けることができます。その結果、EndBlockerの実行には予想以上の時間とリソースがかかり、コンシューマーチェーンの動作が遅くなったり、停止したりすることさえあります。

脆弱性の場所: https://github.com/cosmos/interchain-security/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/consumer/keeper/distribution.go#L103

Vulnerability code snippet:

Vulnerability Trigger Path:

<エンドブロックRDSendRewardsToProvider

2つ目のタイプの状況

このタイプのコンセンサス問題は、直感的な深刻な害をもたらさないかもしれませんが、ブロックチェーン全体の本質であるシステム考慮の原則から、あるいは具体的なシナリオから脆弱性を見ると、それらは次のようになります。しかし、ブロックチェーンの根底にある原理やシステム、あるいは具体的なシナリオの観点からこれらの脆弱性を見た場合、それらがもたらす影響や被害は、他の従来の脆弱性と比べて必ずしも小さいとは言えません。

Case 1

Vulnerability Background: Cosmos SDK Security Advisory Jackfruit

CosmosSDKのx/authzモジュールのValidateBasicメソッドの非決定的な動作は、コンセンサスを停止させる可能性があります。Grant構造体のValidateBasic()検証処理において、ブロック時刻情報ではなく、ノードのローカル時刻情報とその時刻情報を比較すると、ローカル時刻が非決定的であり、個々のノードのタイムスタンプが異なる可能性があるため、コンセンサスの問題につながる可能性があります。

脆弱性のアナウンス:

https://forum.cosmos.network/t/cosmos-sdk-security-advisory-jackfruit/5319

https.//forum.cosmos.network/t/cosmos-sdk-vulnerability-retrospective-security-advisory-jackfruit-october-12-2021/5349

https.align: left;">https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-2p6r-37p9-89p2

Vulnerability code snippet:

Vulnerability patch:

https://github.com/cosmos/cosmos-sdk/compare/v0.44.1.....v0.44.2

タイムスタンプに関する今回のような問題は、Cosmos SDKのような基本的なコンポーネントで発生するだけでなく、さまざまなアプリケーションチェーンで同様の脆弱性が確認されています。

Case 2

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

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

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

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

Vulnerability code snippet:

Vulnerability patch:

ローカルのタイムスタンプの使用方法を変更しました。時間を使うように変更しました。

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

Case 3

Background of the vulnerability: The Prophecy Machine module of the BandChain project

プロジェクトのアドレス：https://github.com/bandprotocol/bandchain/

コードベースのコメントによると、Prophecy Machineプロトコルの違反者に対するペナルティを有効にするために、Prophecy Machineモジュールは誓約の前に実行されなければなりません。SetOrderEndBlockers関数では、Predicate Machineモジュールの前にPledgeモジュールが実行されます。もしプレッジモジュールがプレディクターモジュールより先に実行されると、プレディクターモジュールで行われた検証に基づいて、プレッジしたバリデーターを罰するなどの操作が実装不可能になります。

脆弱性の場所: https://github.com/LeastAuthority/bandchain/blob/master/chain/app/app.go#L221-L225

Vulnerability Code (脆弱性のコード)スニペット:

脆弱性に特化した実装と脆弱性のコメントが完全に逆になっており、Prophecy MachineモジュールがPledgeモジュールの前に来るべきであることがわかります。

Case 4

脆弱性の背景: Sei Cosmosプロジェクトのaccesscontrolモジュール

プロジェクトのアドレス: https://github.com/sei-protocol/sei-cosmos

様々なCosmosコードベースの複数のインスタンスにおいて、go mapの反復はすべてgo言語のマップ型を使用し、それを反復してきました。go言語マップの反復は非決定論的なので、これはノードが異なる状態に到達する原因となり、チェーンの実行を停止させるコンセンサスの問題につながる可能性があります。これを扱うより適切な方法は、マップされたキーをスライスにソートし、ソートされたキーを反復することである。この種の問題はより一般的であり、使用する言語の特徴によってもたらされるものである。

x/accesscontrol/keeper/keeper.goのBuildDependencyDagの実装では、ノードはanteDepSetを反復する。 Goのマッピング反復の非決定的な振る舞いのためである。ValidateAccessOpは2つの異なるタイプのエラーを投げ、コンセンサスを失敗させる可能性がある。

脆弱性の場所: https://github.com/sei-protocol/sei-cosmos/blob/afe957cab74dd05c213d082d50cae02dd4cb6b73/x/accesscontrol/keeper/keeper.go#L314C9-L314C9

脆弱性のあるコードスニペット:

これらのケースに基づくと、次のようになります。チェーンの実行を受動的に停止させる脆弱性が、最も損害を与える傾向があり、その原因の論理的関係は、ブロックチェーン内の個々のブロックの動作に直接影響を与える実行プロセスまで遡ることができることがわかりました。一方、コンセンサス・セキュリティの脆弱性は、多くの場合、それを修正するためにチェーンが積極的にシャットダウンした結果であり、脆弱性の原因はブロックチェーン全体のプロセスと状態にまで遡ることができます。次に説明する資金喪失型の脆弱性とは異なり、資金喪失型の脆弱性は通常、問題の論理的な道筋に基づいて具体的な危険の影響度を判断するのではなく、資金の所有者、資金の量、資金の影響範囲、資金に影響を与える方法などがより懸念されます。

資金の損失

資金の損失タイプの問題は、sdk.MsgとIBCメッセージの論理処理によく見られます。もちろん、チェーンの実行を停止させる脆弱性もあり、具体的な影響は特定の脆弱性に依存するため、ここでは前者に焦点を当てます。加えて、IBCはCosmosエコシステムの非常に重要な部分であるため、IBCの脆弱性のいくつかが関与することは避けられません。IBCへの具体的な攻撃と対応する脆弱性については、次の章に載せて探ります。

資金の損失は、ガスが消費される、資金がロックされて取り出せない、資金が送信中に失われる、計算ロジックのエラーによる資金の損失、資金IDの保存において一意性が保証されないといった論理的な状況でよく見られます。

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

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

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

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

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

Vulnerability code snippet:

Vulnerability Trigger Path:

脆弱性のコンテキスト：SuperNovaプロジェクト

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

地域の独自性は検証されていません。一意性は検証されていません。登録されたゾーンでは、ゾーンIDを使ってBaseDenomの一意性がチェックされますが、これは各ゾーンごとに一意であるべきで、BaseDenomの値が間違って設定されると、資金が失われることになります。このプロジェクトでは、RegisterZoneでベーストークンを設定する前に、BaseDenomがすべてのメインゾーンで一意であることを確認していませんでした。そうでなければ、ユーザーが同じ名前のBaseDenomを含む別の悪意のあるゾーンに資金を保管する可能性があり、その結果、資金が失われることになります。

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

Exploit code snippet:

Vulnerability patch: more DenomDuplicateCheck

上記に加え、チェーンは最初のシナリオの1つがクラッシュによるミントの失敗である場合に実行を停止し、また、資金が失われるのようなものです。

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

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

ステータス更新の欠落。IcaWithdraw()メソッドにおいて、トランザクションが失敗し、バージョンの状態が変更されない場合、WithdrawRecordにアクセスできなくなり、対応する資金が引き出されなくなります。より一般的な理解としては、SendTxの前にstateが設定され、失敗した後にstateが変更されないため、資金の引き出しに失敗し、次回に再び引き出すことができないということです。

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

脆弱性のコードスニペット:

この部分から、資金に関連する操作のロジックの実装がメインであったり、各種メッセージの処理に依存していることはもちろんですが、操作の鋳造に関わるBeginBlockの処理の実装に1つ目のような状況があり、これらの操作に失敗した場合に資金の損失につながるケースもあることがわかります。全体として、私たちの監査を造幣操作に関わるコードモジュールに集中させることで、そのような脆弱性を発見する可能性を大幅に高めることができます。

システムの状態または正常な動作に影響を与える

このタイプの問題は範囲が広く、先ほど説明した最初の2つの危険は、システムの状態または正常な動作に影響を与えるタイプの脆弱性のサブセットと考えることができます。脆弱性の種類のサブセットまた、より論理的なタイプの脆弱性の大きな危険は、かなりの程度まで、脆弱性のこのタイプは、プロジェクトのビジネスロジックと異なるセキュリティリスクに基づいていますが、Cosmos SDKのコンポーネントの類似性のためだけでなく、多くの場合、同じような間違いを犯す特定のコードを実装するための特性のモジュール性を構築し、ここで次のリストを与えるために一般的な脆弱性:

sdk.Msg型での不完全な変数チェック

プロジェクトはsdk.Msgに基づいてさまざまな派生型を実装しているため、Cosmos SDKは既存の型のすべての要素を検出せず、その結果、いくつかの重要な組み込み変数が省略されます。しかし、Cosmos SDKは既存の型のすべての要素を検出しないため、一部の重要な埋め込み変数が省かれ、セキュリティリスクが生じます。left;">脆弱性の背景：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

Exploit code snippet:

これに加えて、Cosmos-SDKセキュリティ勧告Elderflower、Cosmos-SDKセキュリティ勧告Jackfruitは、実際にはValidateBasicチェーンの問題で、前者はValidateBasicの呼び出しが直接抜けており、後者はタイムスタンプ変数のチェックサムに関するメッセージ内部の問題です。これらの問題はアプリケーションチェーンではさらに一般的で、ethermint、pstake-native、quicksilverなどのプロジェクトでは、メッセージを処理するために使用される検証手段に同様のセキュリティホールがあります。

バリデーションタイプ以外にも、sdk.Msgの処理ロジックには、大量のガス消費を伴うループや、不合理なクラッシュ処理などが存在します。これらは、メッセージ処理チェーンの回復メカニズムにより、チェーン停止よりは危険性が低いものの、システムの正常な動作に影響を与えたり、チェーン内の資金が失われたりする可能性があります。チェーンの資金が失われる。

一般的な脆弱性の種類

プロジェクトのビジネスに特有のセキュリティの脆弱性に加えて、一般的な脆弱性モデルもいくつかあります。例えば、ケース3の資金の損失は、メッセージを送信する前に状態を変更することですが、このタイプの脆弱性は、資金を送信する前に自身の状態を変更するスマートコントラクトの脆弱性に非常に似ており、しばしば再突入などの問題をもたらします。このタイプの脆弱性は、資金を送信する前に状態を変更するスマート・コントラクトの脆弱性と非常によく似ており、しばしば再エントリーやレガシー・エラー状態のような問題をもたらす。状態設定とメッセージ送信が密接に連動するこのようなシナリオは、実際ブロックチェーンでは非常に一般的であり、大きな危険を引き起こす脆弱性の多くはこのような問題に起因している。これに加えて、ゼロ化解除の脆弱性、ガス消費バイパス、脆弱なバージョンの使用に似た計算セキュリティの脆弱性もあり、これらはすべてシステムの状態やシステムの正常な動作に影響を与える可能性があります。

一意性の問題

ブロックチェーンでは多数のルックアップ-リード-ストア操作が関与しているため、特定の機能実装では命名の一意性が非常に重要です。例えば、先の資金紛失のケースでは、一意性の問題は、キーなどの重要な要素を表す文字列やバイト配列型の変数に加え、それぞれの命名の末尾に「/」が存在するなど、その接頭辞の構成にリスクがある場合があり、わずかな不注意で文字列の命名が異なる意味に偽造される可能性があり、それが一連の資金紛失や、資金流出などの問題につながることです。資金の損失やコンセンサスの誤りといった一連の問題につながる。

言語機能による問題

このタイプの問題はもう少し広範ですが、golangのマップ反復問題や、rustのパニックメカニズムの一部など、より特徴的で、それゆえに発見しやすいものです。ある言語を使う前に、対応するリスクにつながりそうなポイントをリストアップし、その言語を使うときや監査するときに個別に注意を払うことで、そのようなエラーを可能な限り回避することをお勧めします。

まとめ

Cosmosのエコシステムにおける根本的なセキュリティ問題の調査によると、そのような問題はCosmosのエコシステムに当てはまるだけでなく、他のエコシステムにも適用できる脆弱性モデルがたくさんあることを見つけるのは難しいことではありません。推奨と要約：

インフラの脆弱性に焦点を当てる：CometBFTとCosmos SDKのコアコンポーネントも脆弱である可能性があるため、セキュリティを確保するために定期的な更新と保守が必要です。

サードパーティライブラリの適時レビュー:Cosmosの開発者は、アプリケーションの機能を拡張するためにサードパーティライブラリを使用することがよくあります。しかし、これらのライブラリには潜在的な脆弱性が含まれている可能性があるため、リスクを軽減するために見直し、更新する必要があります。

悪意のあるノード攻撃に注意する：Cosmosエコシステムでは、コンセンサスノードはネットワークの重要なコンポーネントです。ノードのビザンチンフォールトトレラントアルゴリズムは攻撃される可能性があるため、悪質な振る舞いを防ぐためにノードを保護する必要があります。

物理的なセキュリティに注意を払う：無許可のアクセスや潜在的な攻撃を防ぐために、Cosmosノードを実行しているハードウェアとサーバーには物理的なセキュリティ対策が必要です。

必要なコードレビュー：Cosmos SDKとCometBFTエコシステムはオープンな性質を持っているため、開発者とレビュアーは、潜在的なセキュリティ問題を特定し修正するために、カスタムモジュールで書かれたコードだけでなく、コアコードもレビューする必要があります。

エコシステムのツールを警戒する：Cosmosエコシステムには、セキュリティを確保するためにセキュリティレビューと定期的なアップデートが必要なツールやアプリケーションが多数含まれています。

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

このモジュールは、Cosmosの非常に重要な部分であるIBCプロトコル(The Inter-Blockchain Communication protocol)に関するセキュリティ問題に焦点を当てます。IBCは、異種ブロックチェーンが信頼でき、秩序正しく、信頼を最小限に抑えた方法であらゆるデータを転送できるようにするプロトコルです。あらゆるデータに対するプロトコルです。

ビットコインの登場以来、ブロックチェーンは爆発的な成長を遂げてきた。無数の新しいネットワークが誕生し、それぞれが独自の価値提案、合意メカニズム、イデオロギー、構成員、存在意義を持っています。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: トランスポート層を通過したパケットのアプリケーションハンドラを定義する標準。これには、Homogenised Token Transfers (ICS-20)、Non-Homogenised Token Transfers (ICS-721)、Inter-Chain Accounts (ICS-27)が含まれますが、これらに限定されません。

IBCチャート（コスモス開発者ポータルより）。Cosmos Developer Portalより）

IBCプロトコルは、Internet of Blockchainsビジョンに準拠するCosmosのバックボーンです。この意味で、IBCの設計上の選択はTCP/IP仕様の影響を受けています。TCP/IPがコンピュータ通信の標準を定めているのと同様に、IBCはブロックチェーンが通信できるように実装可能な一般的抽象化セットを規定しています。TCP/IPはネットワーク上で中継されるパケットの内容に制限を設けていませんが、IBCも同様です。さらに、HTTPやSMTPなどのアプリケーションプロトコルがTCP/IP上に構築されているのと同様に、同種アセット/非同種アセット転送やクロスチェーン・スマートコントラクト呼び出しなどのアプリケーションインスタンスは、ベースレイヤーとしてIBCプロトコルを使用します。

現在、IBCプロトコルの主な問題は、チャネル伝送とパケット処理についてにあり、もちろん、検証の証明やプロセスの他の側面が比較的大きな問題に登場していないわけではありませんが、それらの問題は比較的小さく、この記事ではIBCプロトコルの一般的な問題に焦点を当てています。IBCプロトコルのモジュール設計により、IBCアプリケーションの開発者は、クライアント、接続、証明の検証といった基本的な細部に集中する必要をなくすことができる。したがって、IBC プロトコル関連の問題は、パケットの受信と処理のための IBCModule インタフェース (onRecvPacket, OnAcknowledgementPacket, OnTimeoutPacket など) のコードパスに多く見られる。など)のコードパスがあります。

一般的な脆弱性の分類

Cosmosのエコシステムでは、IBCプロトコルが接続性のハブとして機能しており、脆弱性の種類としては、IBCプロトコルに関連する脆弱性はより多く、脆弱性が発生する場所はより複雑です。IBCプロトコルの実装は、Cosmos-SDK、CometBFT、その他のモジュールと密接に関連しているため、Cosmosエコシステムの他のモジュールの実装について言及することは避けられない。また、IBCは現在Cosmosエコシステムで使用されているため、ibc-goのドキュメントに記載されているように、主に使用されている言語はGolangです。

紙面の都合上、IBCプロトコルのさまざまな側面やコンポーネントの詳細な分析は行いませんが、いくつかの既存のセキュリティ脆弱性の分類についてのみ説明します。より詳細で包括的な分析をお知りになりたい場合は、CertiKのセキュリティエンジニアまでお気軽にお問い合わせください。

一般的な脆弱性：

1.ネーミングの脆弱性

① 文字列処理の脆弱性

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

2.送信プロセスの脆弱性

① パケットシーケンスの脆弱性

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

2.脆弱性

③パケット認証の脆弱性

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

3. ロジックの脆弱性

① 状態更新の脆弱性

②投票コンセンサスとその他の脆弱性

③その他のロジックの脆弱性

4.ガス消費の脆弱性

既存のIBCについて既存のIBCプロトコルは、そのセキュリティの監査と分析という点で、Web2プロトコルの監査プロセスと類似点が多い。今回は、プロトコルの開発、実装、アプリケーションの拡張という完全なプロセスの観点から、IBCプロトコルのセキュリティ問題と潜在的なリスクのいくつかを分析する。プロトコルの開発は少数の人々や組織によって行われることが多く、あらゆる種類のブロックチェーン組織では、プロトコルの実装と拡張を中心に多くの作業が行われるため、本稿ではこの2つのセキュリティにも焦点を当てる。これは、IBCプロトコルのセキュリティリスクを幅広くカバーすることで、プロトコル上のさまざまなタイプのセキュリティ問題を、対応するリンクやモジュールによりよく分けることができることを考慮してのことである。

脆弱性分析

IBCプロトコルの定式化

ケース1：ICS-07プロトコル、ロジックの脆弱性

脆弱性の背景：アンバンドリング期限の誤った使用

コード内に以下のチェックが存在する：

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

Tendermintのセキュリティモデルによると、以下のようになります。Tendermintのセキュリティモデルによると、時刻tのブロック(ヘッダ)のNextValidatorsにあるバリデータは、t+TrustingPeriodまでは正しく実行される必要があるようです。しかし、ここでのチェックはTrustingPeriodではなくUnbondingPeriodに対して行われる。の間にある場合、そのヘッダーを、不正行為を構成する競合ヘッダーの一つを検証するために使用されるベースラインとして受け入れる。この期間中、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

Exploit code snippet:

プロトコル定義関数

コードの実装

IBC プロトコルの実装

IBCプロトコルの実装リンクは、リストの上部と下部の両方で役割を果たしているため、問題のある場所です。プロトコル仕様の曖昧さを避けることは重要ですが、その後のプロトコルの使用や拡張のために、より基本的で便利なインターフェイスを提供することも重要です。したがって、IBCプロトコルの実装における主な問題は、以下のように分類されます：

1.プロトコルの実装における曖昧さと不規則性

2. プロトコルのセットアップにおけるエラー

プロトコルの実装における曖昧さと不規則性
プロトコルの実装における曖昧さと不規則性
プロトコルの実装における曖昧さと不規則性

Case 1: ICS-20プロトコル、命名の脆弱性

脆弱性の背景: ホスティングアドレスの衝突.GetEscrowAddress()は20バイトのSHA256(ポートID + チャネルID)に切り詰められます。このアプローチには3つの問題があります。

1.ポートとチャネルのドメインが分離されておらず、文字列の連結を使用してもポートとチャネルのドメインが分離されません。例えばポート/チャネルの組み合わせ("transfer", "channel")や("trans", "ferchannel")は同じ管理アドレス、つまり切り詰められたSHA256("transferchannel")を与える。特定のライブラリ対応モジュールがポートおよびチャネル ID を選択できる場合、脆弱性が発生する可能性があります。

2.モジュール・アカウント・アドレス間の競合。任意の英数字文字列が、160ビットのポストイメージサイズを持つ SHA-256 のプリイメージで使用されています。この小さなポストイメージと高速なハッシュ関数の組み合わせにより、誕生日攻撃が可能となり、その安全性はわずか80ビットにまで減少します。これは、2つの異なるホスティングアカウントアドレス間の衝突を見つけるのに、およそ2^80回の推測が必要であることを意味する。SHA256の切り捨てを攻撃する詳細なコスト分析が2018年にTendermintのコンテキストで実施され、この攻撃がコストの観点から実行可能であること、そして衝突を見つけることは、2つの異なるホスティングアカウントが同じアカウントアドレスにマッピングされることを意味することが実証された。これはホスティングアカウントから資金を盗むリスクにつながる可能性があり、その詳細はICS20 GetEscrowAddress pre-image domain overlaps with public keysT:BUG.

3. モジュール式アカウントアドレスと非モジュール式アカウントアドレスの衝突

に記載されています。strong>を参照してください。公開アカウントアドレスは、Ed25519公開鍵の20バイトのSHA-256と同じ方法で構築されます。特定の公開アドレスに対する衝突攻撃を防ぐには160ビットのセキュリティで十分ですが、誕生日攻撃に対するセキュリティはやはり80ビットしかありません。この状況はハーフバースデー攻撃モデルに似ており、一方のアドレスは高速な 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
エクスプロイトコードスニペット:
Protocol Setting Error Issue
Protocol Setting Error Issue
Case 1: IBC Security Advisory Dragonberry、トランスポートプロセスの脆弱性
脆弱性の背景：IBCは、アプリケーションパケットを処理する際にパケットという構造を使用します。タイムアウトの仕組み、同期・非同期の確認の仕組み、対応する証明の検証プロセスによって、パケットは2つの実行プロセスに分けられます。
1.正常な場合：タイムアウト内に成功
2.タイムアウトの場合：タイムアウトに失敗
Dragonberry 脆弱性の概略フローチャート
プロジェクトのアドレス: https://github.com/cosmos/ibc-go/tree/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel

ドラゴンベリーの脆弱性の概略フローチャート。align: left;">脆弱性の場所：https://github.com/cosmos/ibc-go/blob/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel/keeper/timeout.go#L117C28-L117C54
脆弱性のあるコードスニペット:
Case 2: IBC Security Advisory Huckleberry、トランスポートプロセスの脆弱性
脆弱性の背景: UnreceivedPacketsは、クエリに含まれる各シーケンス番号に対応するパケット受信を調べることによってのみレスポンスを構築します。これは順序付けされていないチャネルにのみ適用され、順序付けされたチャネルではパケットレシートの代わりにnextSequenceRecvを使用するからです。そのため、順序付けられたチャネルでは、GetPacketReceipt を使ってシーケンス番号を問い合わせても、その中のレシートを見つけることはできません。
ICS-20FTはほとんど順序のないチャネルで送信し、リピータはトリガとなるタイムアウトパケットを決定するためにこのgrpcエンドポイントに依存しないため、この問題の深刻度はそれほど高くありません。しかし、もしターゲット・チェーンに多数のパケットがあり、IBC 送信のために構成された順序のあるチャネルがあり、grpc レスポンスのページングがない場合、これはパフォーマンスの低下、あるいはサービング・ノードのクラッシュを引き起こす危険性がある。その具体的なトリガープロセスは、次の図で見ることができます。
Huckleberry Vulnerability Schematic Flowchart
プロジェクトのアドレス: 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
Exploit code snippet:
IBCプロトコルの利用と拡張
ケース1: ストライド・エアドロップの脆弱性、ロジックの脆弱性
脆弱性の背景:TryUpdateAirdropClaimこの関数は、IBCパケットの送信者アドレスをsenderStrideAddressというストライドアドレスに変換し、パケットメタデータからairdropIdと新しいairdropアドレスを抽出します。その後、updateAirdropAddressが呼び出され、senderStrideAddressとClaimRecordが更新される。ClaimRecordが更新されると、newStrideAddressはエアドロップを要求できるようになる。ibcはソロマシン接続がIBC対応チェーンを実装することを許可しているので、他のアカウントアドレスをドロップアドレスとして更新することはセキュリティ上のリスクがある。
プロジェクトアドレス: https://github.com/Stride-Labs/stride/tree/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot
脆弱性の場所: https://github.com/Stride-Labs/stride/blob/3a5c7bfcc3b8c5e7dd870f01beb9d9492203/x/autopilot/module_ibc.go#L119
https://github.com/Stride-Labs/stride/blob/3a5c7bfcc3b8c5e7dd870f01beb9d9492203/x/autopilot/keeper/airdrop.go#L17
Exploit code snippet:
Case 2：neutronのIBCモジュールの脆弱性、ガス消費の脆弱性
脆弱性の背景：IBCイベントの確認応答/タイムアウトに対するスマートコントラクトの支払いは十分に検証されていないため、悪意のあるスマートコントラクトによって悪用される可能性があります。OnTimeoutPacketメッセージで悪意のあるスマート・コントラクトに悪用され、ErrorOutOfGasクラッシュを引き起こす可能性がある。これらのクラッシュは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
Vulnerability code snippet:
概要
以上のIBCプロトコルのセキュリティ問題の調査・分析から、IBCプロトコルのセキュリティ問題は、分布範囲が広く、様々な問題があるが、主な問題はやはりIBCプロトコル拡張の実装と使用にあることを見出すのは難しくない。主な問題は、IBCプロトコルの実装とその利用拡張にある。

IBCプロトコルは、IBMのソフトウェアで使用されているように使用することはできません。
上述したIBCチェーンのセキュリティ問題に加え、IBCミドルウェアなど他のセキュリティ問題も浮上しており、将来的には、IBCモジュールのセキュリティ問題がコスモスのエコシステムのセキュリティの重要な部分を占めるようになると考えられています。
まとめ
Cosmosエコシステムのセキュリティを探求・研究する過程で、私たちは複雑な監査、要約、分類作業を経て、Cosmosエコシステムで最も重要なCosmos SDKとIBCプロトコルに関するセキュリティ問題を探求し、豊富な実践経験を通じて、Cosmos SDKとIBCプロトコルに関するセキュリティ問題を探求してきました。多くの一般的な監査の教訓を学びました。
本レポートは、クロスチェーン相互作用をサポートする異種ネットワークを扱う際に直面する課題を浮き彫りにしています。コンポーネントの複雑さと分散化により、これらのコンポーネントのセキュリティ監査を行うことは同様に困難です。既存のセキュリティ経験を通じて、内在するセキュリティリスクの一部をトラブルシューティングする必要があるだけでなく、新たなセキュリティ問題を分析するために、新たなセキュリティシナリオに直面する必要もあります。また、常に新しいセキュリティシナリオに直面し、新しいセキュリティ問題を分析する必要もあります。
それでも私たちは、本レポートにまとめたような一般的なシナリオやセキュリティ問題を通して、異種混合のコスモスエコシステムの全体的なセキュリティを徐々に改善できると信じています。