Cosmos エコシステム セキュリティ ガイド: Cosmos エコシステムのさまざまなコンポーネントのセキュリティ シナリオの分解

この記事には、Cosmos エコシステムにおける過去の主要なセキュリティ脆弱性の分析が含まれているだけでなく、Cosmos エコシステム開発者に最大限のセキュリティ ガイダンスを提供するために、原因、影響、コードの場所などに従っていくつかの一般的なセキュリティ脆弱性も分類されています。 、およびセキュリティ監査人に学習とガイダンスを提供するため、Cosmos のセキュリティ問題のインデックス データを監査します。

原題:「CertiK Exclusive: Deconstructing Cosmos Ecological Security and Facilitating Web3 Interstellar Journey」

執筆者: CertiK

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

*Cosmos 開発コンポーネントがより多くの開発者に好まれるようになっているため、Cosmos エコシステムのセキュリティ問題はより広範な影響を与えることは間違いありません。たとえば、Cosmos SDK の Dragonfruit の脆弱性は、以前に複数の主流パブリック チェーンの通常の動作に影響を与えました。 Cosmos エコシステムの基本コンポーネントは分散化されているため、開発者はさまざまな機能要件に応じてさまざまなコンポーネントを使用または拡張する必要があり、その結果、Cosmos エコシステムのセキュリティ問題も分散し、多様化しています。開発者がコスモスの生態安全保障の現状と対策を構造的に理解するのに役立つ研究が非常に必要です。 *

CertiK チームが独占的にリリースした「Cosmos Ecosystem Security Guide」では、Cosmos エコシステムのさまざまなコンポーネントのセキュリティ シナリオが読みやすい分類で詳しく説明されています*。このレポートには、Cosmos エコシステムにおける過去の主要なセキュリティ脆弱性の分析が含まれているだけでなく、Cosmos エコシステム開発者に最大限のセキュリティ ガイダンスを提供するために、いくつかの一般的なセキュリティ脆弱性をその原因、影響、コードの場所などに従って分類しています。 Cosmos のセキュリティ問題に関する監査インデックス データをセキュリティ監査人に学習およびガイダンスを提供します。 *

*CertiK チームは、継続的な研究とマイニングを通じて、Cosmos と Web3 全体の生態学的セキュリティの向上に貢献してきました。さまざまなプロジェクトの安全性レポートや技術研究を定期的にお届けしますので、引き続きご注目ください。ご質問がございましたら、いつでもご連絡ください。 *

※以下は『コスモス生態安全保障ガイド』全文です👇。 *

＃＃ 概要

Cosmos は オープンソース、オープンかつ拡張性の高い ブロックチェーン クロスチェーン ネットワークであり、世界で最もよく知られているブロックチェーン エコシステムの 1 つです。 Cosmos は CometBFT (旧 Tendermint チーム) によって立ち上げられた、クロスチェーン インタラクションをサポートするヘテロジニアス ネットワークです。複数の独立した並列ブロックチェーンで構成され、分散型ネットワークを形成しています。そのビジョンは、情報のアイランド効果を打ち破り、異なるブロック間の相互運用性を実現することです。鎖。現在のマルチチェーン時代において、ブロックチェーン業界ではクロスチェーンインタラクションの実現が緊急のニーズとなっています。

Cosmos は、特定の垂直分野に焦点を当てたパブリック チェーンに特に適した効率的なクロスチェーン モデルを提供します。 Cosmos はモジュール式のブロックチェーン インフラストラクチャを提供することで、アプリケーション開発者がニーズを満たすパブリック チェーンを選択して使用できる利便性を提供します。

Cosmos エコシステムのアプリケーションとプロトコルは IBC (ブロックチェーン間通信プロトコル) を使用して接続されており、独立したブロックチェーン間のクロスチェーン相互作用が可能になり、資産とデータが自由に流れることができます。 Cosmos のビジョンは、多数の自律的で開発が簡単なブロックチェーンが拡張して相互作用できる可能性を提供する、ブロックチェーンのインターネットを構築することです。

長い間、CertiK はコスモスの生態環境に最大限の注意を払い、研究を続けてきました。私たちは、Cosmos の生態系セキュリティ問題に関して十分な経験を蓄積してきましたが、この研究レポートでは、主に Cosmos SDK のセキュリティ、IBC プロトコルのセキュリティ、CometBFT のセキュリティに焦点を当てた、Cosmos 生態系のセキュリティに関する調査と研究結果を紹介します。 CosmWasm セキュリティ の議論の対象は、Cosmos の基本コンポーネントから Cosmos の基本チェーンまたはアプリケーション チェーンにまで及び、同様の問題の分析と拡張を通じて、読者に Cosmos エコシステムをボトムアップで示します。チェーン自体に関与するセキュリティ ポイント。

Cosmos エコシステムの複雑さと多様性により、既存のセキュリティ問題も多様な特徴を持っています。したがって、この調査レポートはすべての種類のセキュリティ脆弱性を網羅しているわけではありません。** Cosmos エコシステムのより典型的な特徴と存在についてのみ説明しています。連鎖、さらに有害な脆弱性**。他のセキュリティ問題についてさらに詳しく知りたい場合は、CertiK セキュリティ エンジニアにお問い合わせください。

＃＃ 背景

• CometBFT: クロスチェーンのスケーラビリティの基礎

CometBFT は、基盤となるコンセンサス エンジン (CometBFT コア) とユニバーサル アプリケーション ブロックチェーン インターフェイス (ABCI) という 2 つの主要コンポーネントを含む革新的なコンセンサス アルゴリズムです。そのコンセンサス アルゴリズムは PBFT+Bonded PoS ハイブリッド コンセンサスを採用し、ノードがトランザクションを同期的に記録することを保証します。 Interchain のスケーラビリティの中核コンポーネントとして、CometBFT はバリデーターのコンセンサスを通じて Interchain エコシステムのセキュリティ、分散化、整合性を維持します。

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

Cosmos SDK は、開発者が開発プロセスを加速するのに役立つツールキットですし、モジュール式でプラグ可能な機能を提供します。Cosmos SDK を使用すると、開発者は CometBFT コンセンサス アルゴリズムに基づいて独自のブロックチェーンまたは機能コンポーネントを構築できます。便利な開発を実現し、開発時間を短縮しますサイクル。現在、Cronos、Kava、最近発売された dYdX V4 など、多くのブロックチェーン プロジェクトで採用されています。将来の開発計画は、モジュール化と新機能の導入に焦点を当て、開発者がより複雑なモジュール型アプリケーションを作成できるようにし、より広範で強力なエコシステムを育成する予定です。

• IBC プロトコル: 強化された相互運用性とスケーラビリティ

IBC プロトコル (ブロックチェーン間通信プロトコル) は、ブロックチェーン間の安全で分散型の許可のないデータ転送を可能にします。 Cosmosは複数の独立した並列ブロックチェーンから構成される分散型ネットワークであり、リレー技術を用いて異なるブロックチェーン間のクロスチェーンを実現するため、IBCはプロジェクト全体の中核部分と言えます。 Interchain Foundation は現在、スケーラビリティと使いやすさという 2 つのトピックに焦点を当てています。 IBC のスケーラビリティと相互運用性を向上させることで、Cosmos はエコシステムの能力をさらに強化し、ブロックチェーン、アプリケーション、スマート コントラクト間のシームレスな相互作用を可能にします。

• CosmWasm: 分散型のパーミッションレス展開のロックを解除

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

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

チェーン開発者の観点から見ると、Cosmos 上の現在のエコロジカル チェーンに必要なカスタマイズ機能のほとんどは、Cosmos SDK に依存することで完了できます。パフォーマンスなどを考慮して、チェーン開発者は独自の IBC モジュールをカスタマイズします。さらに、少数のチェーンは CometBFT コアなどの基盤となるエンジンを変更およびカスタマイズします。スペースの制限により、この調査レポートは当面実施されません。この調査レポートは、Cosmos SDK と IBC プロトコルの技術的なポイントとセキュリティ問題の分析に焦点を当てます。

Cosmos SDK セキュリティ ガイド

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

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

セキュリティ監査の観点からは、監査の目的を包括的に把握し、あらゆる角度からセキュリティ リスクを十分に考慮する必要がありますが、セキュリティ研究の観点からは、重大な影響を引き起こす可能性のあるセキュリティの脆弱性にさらに注意を払う必要があります。 time 一定期間内に最大の安全上の危険を可能な限り回避し、統合サービスプロバイダーにより効果的な支援を提供します。この観点から、危険度が高く影響が大きい脆弱性をいくつか分類し、その脆弱性モデルを分析することは非常に必要かつ価値のあることです**。

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

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

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

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

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

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

**3 提案ブロックに含まれます: **各ラウンドの開始時に、提案者は最新のトランザクションを含むブロックを作成し、最後に完全なノードがコンセンサス検証を担当し、ブロックを受け入れるか空のトランザクションに投票することに同意します。ゾーンの部分。

**4. 状態変更: **DeliverTx は、CheckTx と同様に、ブロック内のトランザクションを反復するために呼び出されますが、Deliver モードで runTx を呼び出し、状態変更を実行します。 MsgServiceRouter は、トランザクション内のさまざまなメッセージをさまざまなモジュールにルーティングするために呼び出され、Msg Server で対応する各メッセージを実行します。その後、メッセージの実行後にチェックが実行され、失敗した場合は状態が復元されます。実行中に、ガス メーターを使用して、燃料 (ガス) の使用量を追跡します。燃料エラーが発生した場合 (燃料不足など)、状態の変更は元に戻り、実行失敗後と同じ結果になります。

5 ブロックの送信: ノードが十分なバリデーター投票を受け取ると、ブロックチェーンに追加する新しいブロックを送信し、アプリケーション層での状態遷移を完了します。

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

以下は Cosmos SDK の具体的な実行ロジックです。これは、以下の脆弱性を引き起こすパスを分析するときに簡単に読んで理解できます。

Cosmos SDK は、ABCI の特定の実行ロジックに焦点を当てています

一般的な脆弱性の分類

脆弱性の分類を理解する前に、危険なセキュリティ脆弱性をより適切に特定し、潜在的なセキュリティ リスクを可能な限り回避するために、脆弱性レベルの基本的な分類を行う必要があります。

危険性の程度と影響範囲を考慮して、私たちは主にクリティカルおよび重大と評価されたセキュリティ脆弱性に重点を置いています。これらは通常、次のリスクを引き起こす可能性があります。

1. チェーンが動かなくなる

2. 資金の損失

3. システムステータスまたは通常の動作に影響を与える

これらの危険の原因は、多くの場合、次の種類のセキュリティ脆弱性です。

1. サービス拒否

2. ステータス設定が間違っている

3. 検証が不足している、または不合理である

4. 一意性の問題

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

6. 実装における論理的な抜け穴

7. 言語特性の問題

脆弱性分析

Cosmos のエコロジカルなモジュール性の特殊性により、さまざまなチェーン実装では、モジュールが相互に使用したり、モジュール内で相互に呼び出したりするケースが非常に多く、脆弱性のトリガー パスと制御可能なパスが一致しない場合があります。脆弱性トリガー位置変数の脆弱性を分析しています 特定のトリガー理由を検討するときは、トリガー パスだけでなく、脆弱性の主要な変数の制御可能なパスにも焦点を当てる必要があります。これは、脆弱性をより適切に定義するのに役立ちます脆弱性モデル。

チェーンの動作が停止しました

ほとんどの場合、チェーンの実行が停止する原因は、単一ブロックの実行時の問題です。ただし、Cosmos の歴史的な開発においては、チェーンを修復するために積極的に停止する必要があるというコンセンサスのあるセキュリティ脆弱性もありました。コンセンサスタイプのセキュリティ脆弱性は、チェーンの実行停止を引き起こす影響の観点からも説明されます。これら 2 つのタイプの問題については、個別に説明します。

1 つ目の状況は、一般的なサービス拒否タイプの脆弱性で、具体的な理由は主に、ループ境界がユーザーの影響を受ける可能性のある不適切なクラッシュ処理とトラバーサル操作です。このような脆弱性により、チェーンの動作が一時停止したり、速度が低下したりすることがよくあります。

前回の記事で述べたように、Cosmos SDK と CometBFT は Cosmos エコシステムの主要なインフラストラクチャであり、これらは Cosmos の基本チェーンによって使用されるだけでなく、さまざまなアプリケーション チェーンでもアーキテクチャに基づいて独自のロジックを実装するため、すべてが準拠しています。 CometBFT の ABCI インターフェイス。ルール、その攻撃対象領域の焦点も ABCI インターフェイスにあります、Chain Halt を引き起こす可能性のあるセキュリティ脆弱性のほとんどは、ブロック コードの実行に直接影響を与える可能性がある問題であるため、それらが発生したパスは、基本的に BeginBlock インターフェイスと EndBlock インターフェイスまで追跡できます。

2 番目のタイプの状況はコンセンサスに影響を与える脆弱性で、通常はさまざまなチェーンの実装に関連しており、現在、一部のロジック処理の検証、時間調整、ランダム性の問題で一般的であることが知られています。このような脆弱性は本質的にブロックチェーンの分散化原理に影響を与えるため、直感的には大きな影響を与えないかもしれませんが、悪意を持って設計されている場合には、より大きなセキュリティ リスクを引き起こすことになります。

カテゴリー 1

• ケース 1: SuperNova プロジェクト

脆弱性の背景: コイン配布操作におけるアドレス検証の欠如により、操作が失敗し、資金が失われます。鋳造モジュールでは、各トークンの鋳造はステーク量に応じて異なります。ただし、プールが存在しない場合、またはコントラクト アドレスが正しく入力されない場合、ミント モジュールで予期しない動作が発生し、ブロックチェーンの機能が停止する可能性があります。報酬プール モジュールでは、プール コントラクト アドレスは検証されません。配布操作が失敗した場合、チェーンは単に実行を停止します。

脆弱性の場所:

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

脆弱性トリガーパス:

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

Keeper.DistributeMintedCoin

Keeper.distributeLPIncentivePools

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

脆弱性パッチ:

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

アドレス検証は、根本原因からアドレスが間違っている可能性を排除するために、MsgCreateCandidatePool の処理 (つまり、プールの作成) 時にメッセージに対して実行されます。

• ケース 2: Cosmos インターチェーン セキュリティ プロジェクト

プロジェクトアドレス:

脆弱性の背景: バリデーターは、同じブロック内で複数の AssignConsumerKey メッセージを送信することにより、プロビジョニング チェーンを遅くする可能性があります。 x/ccv/provider/keeper/key_assignment.go で定義されている AssignConsumerKey 関数を使用すると、バリデーターは承認されたコンシューマー チェーンにさまざまな ConsumerKey を割り当てることができます。これを行うために、consumerAddrsToPrune AddressList は要素を追加します。この AddressList は x/ccv/provider/keeper/relay.go の EndBlocker 内でトラバースされるため、攻撃者はこれを使用してプロバイダー チェーンの速度を低下させることができます。この攻撃を実行するために、悪意のある攻撃者は複数の AssignConsumerKey メッセージを含むトランザクションを作成し、これらのトランザクションをプロバイダー チェーンに送信できます。 ConsumerAddrsToPrune AddressList のベースは、送信された AssignConsumerKey メッセージと同じになります。その結果、EndBlocker の実行には予想よりも多くの時間とリソースがかかり、プロビジョニング チェーンが遅くなったり、停止したりすることがあります。

脆弱性の場所:/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/provider/keeper/key_assignment.go#L378

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

脆弱性トリガーパス:

msgServer.AssignConsumerKey

Keeper.AssignConsumerKey

AppModule.EndBlock

エンドブロックCIS

LeadingVSCMaturedPackets を処理する

ハンドルVSCMaturedPacket

PruneKeyAssignments

• ケース 3: Quicksilver プロジェクト - Airdrop モジュール

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

脆弱性の場所: ‍60f4047e2f2f403d67701b030e/x/airdrop/keeper/abci.go#L15

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

脆弱性トリガーパス:

AppModule.EndBlock

Keeper.EndBlocker

Keeper.EndZoneDrop

脆弱性パッチ:

パニック処理コードは直接削除され、エラー ログの記録に置き換えられました。

• ケース 4: Cosmos インターチェーン セキュリティ プロジェクト

プロジェクトアドレス:

脆弱性の背景: 攻撃者は、提供チェーンの報酬アドレスに複数のトークンを送信することで、サービス拒否攻撃を実行できます。

コンシューマ チェーンの EndBlocker 実行プロセスでは、x/ccv/consumer/keeper/distribution.go で定義された SendRewardsToProvider 関数が tstProviderAddr 内のすべてのトークンの残高を取得し、プロバイダ チェーンに送信します。これを達成するには、報酬アドレスで見つかったすべてのトークンを反復処理し、IBC 経由で提供チェーンに 1 つずつ送信する必要があります。誰でも報酬アドレスにトークンを送信できるため、攻撃者は、たとえばトークン ファクトリ モジュールを備えたチェーンを使用して、さまざまな単位のトークンを多数作成して送信し、サービス妨害攻撃を開始することができます。したがって、EndBlocker の実行には予想より多くの時間とリソースがかかり、消費チェーンが遅くなったり、停止したりすることがあります。

脆弱性の場所:/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/consumer/keeper/distribution.go#L103

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

脆弱性トリガーパス:

AppModule.EndBlock

エンドブロック

エンドブロックRD

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

2 番目のタイプの状況

この種のコンセンサス問題は直観的には重大な害をもたらさないかもしれませんが、ブロックチェーン全体の本質的な原理やシステムを考慮したり、特定のシナリオからこれらの脆弱性を検討したりすると、それらがもたらす影響と害は必ずしも明らかではありません。さらに、この種の脆弱性には共通点もあります。

• ケースその 1

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

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

脆弱性に関する通知:

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

脆弱性パッチ:

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

• ケース 2

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

プロジェクトアドレス:

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

脆弱性の場所: _msgs.go#L14

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

脆弱性パッチ:

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

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.Nano秒()) _, err = k.IcaControllerKeeper.SendTx(ctx, chanCap, connectionId, portID, packetData, uint64(timeoutTimestamp) ))

• ケース 3

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

プロジェクトアドレス:

コードベース内のコメントは、Oracle プロトコルの違反者に対するペナルティを実装するために、ステーキング前に Oracle モジュールを実行する必要があることを示しています。コード内の出現順序は次のとおりです。 SetOrderEndBlockers 関数では、pledge モジュールが oracle モジュールの前に実行されます。ステーキングモジュールが oracle モジュールの前に実行された場合、oracle モジュールで行われた検証に基づいてステーキングなどのバリデーターにペナルティを課すことは不可能になります。

脆弱性の場所:

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

脆弱性の具体的な実装と脆弱性の注釈が完全に逆になっており、oracle モジュールが pledge モジュールよりも前にランク付けされる必要があることがわかります。

• ケース 4

脆弱性の背景: Sei Cosmos プロジェクトのアクセス制御モジュール

プロジェクトアドレス:

さまざまな Cosmos コード ベースの複数のインスタンスでは、go マップの反復では go 言語のマップ タイプを使用し、それを反復します。 Go 言語マップの反復は非決定的であるため、これによりノードが異なる状態に到達し、コンセンサスの問題が発生してチェーンの実行が停止する可能性があります。より適切なアプローチは、マップ キーをスライスにソートし、ソートされたキーを反復処理することです。このタイプの問題は比較的一般的で、言語機能の適用によって発生します。

x/accesscontrol/keeper/keeper.go の BuildDependencyDag の実装では、ノードは anteDepSet を反復します。 Go のマップ反復の非決定的な動作により、ValidateAccessOp には 2 つの異なるタイプのエラーが発生する可能性があり、コンセンサスが失敗する可能性があります。

脆弱性の場所:/blob/afe957cab74dd05c213d082d50cae02dd4cb6b73/x/accesscontrol/keeper/keeper.go#L314C9-L314C9

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

これらの事例によれば、チェーンの実行を受動的に停止させる脆弱性が最も有害であることが多く、脆弱性の原因間の論理的関係は、システムの動作に直接影響を与える実行プロセスまで遡ることができます。ブロックチェーン内の単一のブロック。一部のコンセンサスセキュリティの脆弱性については、それらを修復するためにチェーンの実行が停止することが多く、脆弱性の原因間の論理的関係は、全体的な動作プロセスとブロックチェーンのステータスまで遡ることができます。次に説明するキャピタル・ロスを引き起こす脆弱性の焦点とは異なり、キャピタル・ロスを引き起こす脆弱性は、通常、問題の論理的な経路に基づいてその具体的な危険な影響を判断するのではなく、資金の所有者により注意を払います。 , ファンドの金額、ファンドに影響を与える範囲、ファンドに影響を与える方法など。

資金損失

資金損失の問題は、sdk.Msg および IBC メッセージの論理処理でよく発生します。もちろん、チェーンの実行を停止させる可能性のある抜け穴もいくつかあります。具体的な影響は影響によって異なります。特定の抜け穴に関しては、以前はここでした。さらに、IBC は Cosmos エコシステムの非常に重要な部分であるため、IBC のいくつかの脆弱性が必然的に含まれます。IBC の特定の攻撃対象領域とそれに対応する脆弱性については、次の章で説明します。

資金の損失は、ガスの消費、資金がロックされて引き出しできない、送信中の資金の損失、資金損失を引き起こす計算ロジックエラー、資金ストレージ ID の一意性が保証されていないなどの論理的な状況でよく発生します。

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

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

プロジェクトアドレス:

ゾーンの小数点以下の桁が 18 より大きい場合、資金がロックされる可能性があります。このプロジェクト コードでは、リージョンの小数点以下の桁数に上限はなく、18 桁を超えることができます。 ClaimSnMesssage では、ユーザーが共有トークンを要求する場合に ClaimShareToken が使用されます。ただし、領域の小数点以下の桁が 18 より大きい場合、変換は失敗し、システムからアセットを抽出できません。したがって、領域の小数点以下の桁数を制御することにより、トランザクションのクラッシュ失敗を直接引き起こすことができます。

脆弱性の場所:/blob/v0.6.3/x/gal/keeper/claim.go#L167

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

脆弱性トリガーパス:

msgServer.ClaimSnAsset

Keeper.ClaimShareToken

Keeper.ConvertWAssetToSnAssetDecimal

精度乗数

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

プロジェクトアドレス:/

ゾーンの一意性は検証されていません。登録されたエリアでは、エリア ID を使用してベース トークン (BaseDenom) の一意性を確認します。各エリアの BaseDenom は一意である必要があります。ベース トークンの値が誤って設定されている場合、資金の損失につながります。 RegisterZone にベース トークンを設定する前に、プロジェクトは BaseDenom がすべてのメイン ゾーンで一意であることを保証していませんでした。そうでない場合、ユーザーが同じ BaseDenom を含む別の悪意のあるゾーンに資金を保管し、資金が失われる可能性があります。

脆弱性の場所:/blob/v0.6.3/x/icacontrol/keeper/msg_server.go#L99

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

脆弱性パッチ: DenomDuplicateCheck チェックを追加しました

また、チェーンが停止する最初のケースは、クラッシュによる鋳造失敗であり、これもキャピタルロスの一種です。

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

プロジェクトアドレス:/

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

脆弱性の場所:/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/gal/keeper/msg_server.go#L356

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

ケースのこの部分によると、資金関連の操作の実装ロジックは主にさまざまなメッセージの処理に依存していることがわかります。もちろん、最初のタイプのケースである鋳造操作のようなケースもあります。 BeginBlock 実行プロセスこれらの操作が失敗すると、資金が失われる可能性もあります。全体として、ファンドの運用に関係するコード モジュールに焦点を当てて監査を行うことで、そのような脆弱性を発見する可能性を大幅に高めることができます。

システムのステータスまたは通常の動作に影響します

この種の問題の範囲は比較的広く、今説明した最初の 2 つの危険は、実際には、システムの状態や通常の動作に影響を与える脆弱性タイプのサブセットと考えることができます。さらに、より危険なのは、一部の論理タイプの脆弱性です。このような脆弱性は、プロジェクトのビジネス ロジックに応じてさまざまなセキュリティ リスクを生成しますが、これは Cosmos SDK コンポーネントの構造に起因します。類似性とモジュール性により、特定のコードを実装するときに同様の間違いがよく発生します。一般的なタイプの脆弱性は次のとおりです。

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

さまざまなプロジェクトが sdk.Msg に基づいてさまざまな派生型を実装しているため、Cosmos SDK はそれに応じて既存のすべての型の要素を実際に検出するわけではなく、その結果、いくつかの主要な埋め込み変数の検出が省略されることになり、一定のセキュリティ リスクが存在します。

• ケース 1: Cosmos SDK セキュリティ アドバイザリー Barberry

脆弱性の背景: MsgCreatePeriodicVestingAccount.ValidateBasic 検証メカニズムには、アカウントの生存などのステータスに関する判断が欠けています。 x/auth で定義された PeriodicVestingAccount を使用すると、攻撃者は被害者のアカウントを、入金は許可するが引き出しは許可しない悪意のあるアカウントとして初期化することができます。ユーザーが自分のアカウントに資金を入金すると、これらの資金は永久にロックされ、ユーザーが引き出すことはできません。

脆弱性パッチ:

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

さらに、Cosmos-SDK セキュリティ アドバイザリー エルダーフラワーとコスモス SDK セキュリティ アドバイザリー ジャックフルーツは、実際には 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 プロトコル セキュリティ ガイド

このモジュールでは、IBC プロトコル (ブロックチェーン間通信プロトコル) に関連するセキュリティ問題に焦点を当てます。 IBC プロトコルは Cosmos の非常に重要な部分です。その役割は、さまざまなチェーン間にインタラクティブなブリッジを構築することです。他のタイプのクロスチェーン ブリッジがいくつかの比較的独立した問題に対する解決策を提供する場合、IBC プロトコルは統一されたソリューションを提供すると言えます。チェーン間の相互作用の問題に対する基本的な解決策と基礎となる技術サポート。 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: トランスポート層を通過するパケットのアプリケーション ハンドラーを定義する標準。これには、代替トークン転送 (ICS-20)、非代替トークン転送 (ICS-721)、およびチェーン インターアカウント (ICS-27) が含まれますが、これらに限定されません。 ) は、アプリケーション カテゴリの ICS にあります。

IBC チャート (Cosmos 開発者ポータルより)

IBC プロトコルは、ブロックチェーンのインターネットに関する Cosmos のビジョンの根幹です。この意味で、IBC 設計の選択は TCP/IP 仕様の影響を受けました。 TCP/IP がコンピューター通信の標準を設定する方法と同様に、IBC はブロックチェーンの通信を可能にするために実装できる一連の共通の抽象化を指定します。 TCP/IP はネットワークを介して中継されるパケットの内容に制限を設けず、IBC も同様です。さらに、HTTP や SMTP などのアプリケーション プロトコルが TCP/IP 上に構築されるのと同様に、同種アセット/非同種アセットの送信やクロスチェーン スマート コントラクト呼び出しなどのアプリケーション インスタンスも、基本層として IBC プロトコルを使用します。

現時点で IBC プロトコルで発生している主な問題は、チャネル伝送とデータ パケット処理に関するものであり、もちろん証明検証などの面でも大きな問題はありますが、それらの問題は比較的少ないです。よくある質問。 IBC プロトコルのモジュール設計により、IBC アプリケーション開発者は、クライアント、接続、証明の検証などの低レベルの詳細について心配する必要がありません。ただし、IBCModule インターフェイスと対応する Keeper 処理メソッドを実装する必要があるため、データ パケット (onRecvPacket、OnAcknowledgementPacket、OnTimeoutPacket など) を受信して処理する IBCModule のインターフェイスのコード パスに多くの IBC プロトコル関連の問題が発生します。

一般的な脆弱性の分類

Cosmos エコシステムでは、IBC プロトコルが接続ハブとして機能します。脆弱性の種類で見ると、IBC プロトコルに関連する脆弱性の方が豊富であり、脆弱性の場所はより複雑です。IBC プロトコルとモジュールの関連実装により、脆弱性の場所はより複雑です。 Cosmos-SDK や CometBFT など、緊密に統合されているため、Cosmos エコシステムの他のモジュールの実装については必然的に以下で説明します。なお、IBCは現在Cosmosエコシステムで主に使われているため、言語としては依然としてGolangが主流となっていますが、詳しくはibc-go関連ドキュメントを参照してください。

紙面の都合により、ここでは IBC プロトコルの各リンクとコンポーネントの詳細な分析は行いません。既存のセキュリティ脆弱性のいくつかのみを分類して説明します。より詳細で包括的な分析が必要な場合は、CertiK にお問い合わせください。セキュリティ エンジニアの意見交換とディスカッション。

一般的な脆弱性のカテゴリ:

1. ネーミングの脆弱性

①文字列処理の脆弱性

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

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

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

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

③パケット認証の脆弱性

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

3 つの論理的な抜け穴

① ステータス更新の脆弱性

② 投票のコンセンサスとその他の抜け穴

③その他の論理的な抜け穴

4. ガス消費の脆弱性

既存の IBC プロトコルは、セキュリティの監査と分析のプロセスにおいて、Web2 プロトコルの監査プロセスと多くの類似点がありますが、今回はプロトコルの策定、実装、アプリケーション拡張の完全なプロセスの観点から分析します。 IBC プロトコルの潜在的なリスク。プロトコルの策定は少数の人や組織によって完了することが多いため、さまざまなブロックチェーン組織にとって、より多くの作業がプロトコルの実装とアプリケーションの拡張に集中しているため、この記事でもこの 2 つの点について説明することに重点を置きます。これは、IBC プロトコルのセキュリティ リスクが幅広くカバーされており、プロトコル上のさまざまな種類のセキュリティ問題を対応するリンクとモジュールに適切に分割できるためです。

脆弱性分析

IBC 契約の策定

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

脆弱性の背景: 拘束解除期間の誤った使用

コードには次のチェックが存在します。

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

Tendermint セキュリティ モデルによれば、時刻 t におけるブロック (ヘッダー) の NextValidators 内のバリデーターは、t+TrustingPeriod より前に正しく実行される必要があり、その後は他の動作が行われる可能性があります。ただし、ここでチェックされるのは、TrustingPeriod ではなく UnbondingPeriod です (UnbondingPeriod > TrustingPeriod)。 consState の期間が TrustingPeriod と UnbondingPeriod の間にある場合、そのヘッダーは、不正行為を構成する競合するヘッダーの 1 つを検証するためのベースラインとして受け入れられます。この間、consState.NextValidators のバリデーターは信頼できるとみなされなくなり、敵対的な元バリデーターはリスクを負わずにクライアントをシャットダウンできます。

プロジェクトアドレス:

脆弱性の場所: #misbehaviour-predicate

_handle.go#L96

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

プロトコル定義機能

コード

IBC プロトコルの実装

IBC プロトコルの実装リンクは、過去と次を繋ぐ役割を果たすため、問題が発生しやすい箇所であり、プロトコル仕様の曖昧さは極力避ける必要があり、また、プロトコルのその後の適用と拡張のための、より基本的で便利な基盤を提供する必要があります。したがって、ここでは、IBC プロトコルの実装における主要な問題を小さく分類します。すなわち、次のとおりです。

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

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

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

• ケース 1: ICS-20 プロトコル、命名脆弱性

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

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

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

3 モジュール アカウント アドレスと非モジュール アカウント アドレス間の競合。公開アカウントのアドレスは、Ed25519 公開キーの 20 バイトの SHA-256 と同じように構成されています。特定のパブリック アドレスに対するコリジョン攻撃を防ぐには 160 ビットのセキュリティで十分ですが、誕生日攻撃に対して利用できるセキュリティは 80 ビットのみです。この状況は、一方のアドレスが高速な SHA-256 によって生成され、もう一方のアドレスが比較的低速な Ed25519 公開鍵計算によって生成されるハーフ バースデー攻撃パターンに似ています。このシナリオはより安全ですが、依然としてエスクローアカウントやパブリックアカウントに対する潜在的な攻撃の可能性があります。

プロジェクトアドレス:

脆弱性の場所:

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

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

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

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

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

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

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

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

Dragonberry の脆弱性原則のフローチャート

プロジェクトアドレス:

脆弱性の場所:

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

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

脆弱性の背景: UnreceivedPackets は、クエリに含まれる各シーケンス番号に対応するパケット受信を見つけて応答を構築するだけです。順序付けされたチャネルはパケット受信の代わりに nextSequenceRecv を使用するため、これは順序がずれたチャネルにのみ適用されます。したがって、注文されたチャネルでは、GetPacketReceipt を介してシリアル番号をクエリしても、領収書は見つかりません。

ICS-20 FT によって送信されるチャネルはほとんどが故障しており、リピーターはトリガーとなるタイムアウト パケットを決定するためにこの grpc エンドポイントに依存しないため、この問題の重大度は軽微です。ただし、ターゲット チェーンに大量のパケットがあり、順序付けされたチャネルが IBC 送信用に設定されており、grpc 応答がページングされない場合は、パフォーマンスの低下やサービス ノードのクラッシュを引き起こすリスクが生じます。具体的なトリガープロセスを以下の図に示します。

ハックルベリーの脆弱性原則のフローチャート

プロジェクトアドレス:

脆弱性の場所:keeper/grpc_query.go#L408

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

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

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

脆弱性の背景: TryUpdateAirdropClaim この関数は、IBC パケットの送信者アドレスを senderStrideAddress という名前のストライド アドレスに変換し、パケットのメタデータから airdropId と新しいエアドロップ アドレス newStrideAddress を抽出します。次に、UpdateAirdropAddress を呼び出して、senderStrideAddress と ClaimRecord を更新します。 ClaimRecord のアップデートにより、newStrideAddress がエアドロップを受信できるようになります。ただし、ここでの更新関数は、送信者によって要求されたアドレスが空であるかどうかを検証するだけであり、newStrideAddress は検証しません。ibc ではソロ マシンが IBC 対応を実装するチェーンに接続できるため、他のアカウントを更新する可能性があります。アドレスをエアドロップアドレスとして使用する セキュリティリスク。

プロジェクトアドレス:

脆弱性の場所: _ibc.go#L119

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

• ケース 2: 中性子 ibc モジュールの脆弱性、ガス消費の脆弱性

脆弱性の背景: IBC イベントの確認/タイムアウトに対してスマート コントラクトによって支払われる料金は十分に検証されていないため、悪意のあるスマート コントラクトがこれを悪用して、OnAcknowledgementPacket および OnTimeoutPacket メッセージ処理中に ErrorOutOfGas クラッシュを引き起こす可能性があります。これらのクラッシュは outOfGasRecovery の実行によって回復されません。つまり、トランザクションはブロックに含まれず、IBC リレーがメッセージを繰り返し送信することになり、最終的にリレーが資金を失い、ネットワークが大量のパケットを破棄する可能性があります。危害。

プロジェクトアドレス:

脆弱性の場所:

x/interchaintxs/keeper/ibc_handlers.go#L62

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

＃＃＃ まとめ

IBC プロトコルのセキュリティ問題に関する上記の調査と分析によると、IBC プロトコルのセキュリティ問題が広く分散しており、多様であることを発見するのは難しくありませんが、主な問題は、IBC プロトコルの実装とアプリケーションの拡張において依然として発生しています。 IBC プロトコル**。主要なアプリケーション チェーンは、自社のビジネス ニーズを満たし、運用効果を最適化するために、従来のモジュールの機能を徐々に充実させ、改善していますが、対応する IBC モジュールにさまざまなコード実装も追加しています。

上記のIBCリンクのセキュリティ問題に加えて、IBCミドルウェアなど他のセキュリティ問題も浮上しており、将来的にはIBCモジュールのセキュリティ問題がコスモスのエコロジーセキュリティの重要な部分になると考えています。

要約する

Cosmos エコシステムのセキュリティを調査および研究する過程で、私たちは複雑な監査、要約、分類作業を経て、Cosmos エコシステムで最も重要な Cosmos SDK および IBC プロトコルのセキュリティ問題について議論し、豊富な分析を通じて実践的な経験。多数の一般的な監査経験をまとめたものです。

このレポートは、クロスチェーン インタラクションをサポートする異種ネットワークに直面する際に直面する課題を強調しています。その構成要素の複雑さと分散により、これらのコンポーネントに対してセキュリティ監査を実行することも同様に困難です。既存のネットワークを使用するだけでなく、一部の固有のセキュリティ リスクをトラブルシューティングするにはセキュリティの経験が必要ですが、常に新しいセキュリティ シナリオに直面し、新しいセキュリティ問題を分析する必要もあります。

それにもかかわらず、私たちは、このレポートにまとめられたいくつかの一般的なシナリオとセキュリティ問題を通じて、異種ネットワーク Cosmos エコシステムの全体的なセキュリティを徐々に改善できると信じています。