HN 日本語サマリー

← 一覧へ戻る
セキュリティ

CosmosEscape: Azure Cosmos DBの全データベースを乗っ取る

CosmosEscape: Taking over Every Database in Azure Cosmos DB (wiz.io)

41 pointsby uvuv10 コメント

要約

Wiz Researchは、Azure Cosmos DBのGremlin APIに存在する重大な脆弱性「CosmosEscape」を発見しました。この脆弱性を悪用すると、Microsoft自身のデータベースを含むサービス内のあらゆるデータベースが侵害される可能性がありました。Microsoftはこの問題を完全に修正し、Cosmos Master Keyを廃止するとともに、同様の攻撃を防ぐための新たなガードレールを導入しました。

全文翻訳

Wiz Researchは、Azureの主力データベースサービスであるAzure Cosmos DBのGremlin APIを通じて、重大な脆弱性CosmosEscapeを発見しました。この脆弱性は、Microsoft自身の内部データベースを含む、サービス内のあらゆるデータベースを侵害するために悪用される可能性がありました。これにより、クロスサービス攻撃が可能になります。 CosmosEscapeを通じて、攻撃者はCosmos Master Keyと呼ばれる、プラットフォーム全体に影響を及ぼす秘密情報を取得できた可能性があります。このキーは、2つの非常に強力な機能をもたらしました。 テイクオーバー - 要求に応じて任意のCosmos DBアカウントのプライマリキーを取得し、完全な読み取りおよび書き込みアクセスを可能にします。 列挙 - サブスクリプションやテナントIDなどの特定の組織識別子でフィルタリングできる機能により、サービス上のすべてのデータベースを一覧表示できます。 これらを組み合わせることで、プラットフォーム規模での精密なターゲティングが可能になりました。特定の組織のデータベースを特定し、それを侵害することまで、すべて公開されているエンドポイントから実行できました。 Cosmos DBはMicrosoft内部でも広く使用されており、Microsoft Entra ID、Microsoft Teams、Microsoft CopilotなどのサービスがデータをCosmos DBに保存しています。これらのデータベースも、この脆弱性を通じてアクセス可能でした。 Microsoftは現在、Cosmos Master Keyを廃止するなど、この問題を完全に修正しました。また、Microsoftは同様の攻撃を防ぐためにCosmos DBに新たなガードレールを導入しました。 図1: CosmosEscapeの影響 この調査は、AI脆弱性リサーチャーであるAtlasの初期バージョンによって支援されました。Atlasからのさらなる発表にご期待ください。 必要な対応 Microsoftはこの問題を完全に修正しました。顧客による対応は不要です。Microsoftは徹底的な調査を実施し、このブログで説明されている研究以外の悪用証拠は見つかりませんでした。 単一のクエリからすべてのデータベースをアンロックするまで Cosmos DBは複数のクエリAPIをサポートしており、その中には人気のグラフクエリ言語であるGremlinも含まれます。 // 30歳以上の全ユーザーとその友人名を検索 g.V().hasLabel('user').has('age', gt(30)).out('knows').values('name') Cosmos DBに対してGremlinクエリを実行している際に、疑わしい.NET例外に気づきました。ほとんどのオープンソースGremlinスタックはJVMベースであるため、この例外はCosmos DBがカスタムGremlinエンジンを使用していることを示唆していました。これは興味深い点でした。標準的なSQLとは異なり、エンジンがクエリを組み込み操作の固定セットにマッピングするのに対し、Gremlinサーバーはしばしばクエリを実行可能コードにコンパイルし、制限された環境で実行します。過去には、これらのサンドボックスはあまり堅牢ではありませんでした。Cosmos DBのGremlinサンドボックスも脆弱である可能性が疑われました。 そして、その疑いは的中しました。Cosmos DBのエンジンはGremlinクエリを.NETコードに変換し、クエリがGremlin操作を超えて到達しないように設計された一連の制限を適用しました。しかし、これらの制限は.NETリフレクションを十分に考慮しておらず、ファイル読み取り、書き込み、そして最終的には任意のコード実行プリミティブを、すべて自分のデータベースに対するクエリを通じて開発することを可能にしました。 以下の画像は、Cosmos DBバックエンドでhostnameコマンドを実行させた、私たちのデータベースに対して実行された特別に細工されたGremlinクエリの出力です。 図2: Gremlin API経由でCosmos DBバックエンドでhostnameを実行。 完全なクエリは、今後のBlackHat USAでの発表をご覧ください。 Gremlinサンドボックスをバイパスすることで、顧客の代わりに顧客クエリを実行するDB Gateway上でコード実行を獲得しました。このDB Gatewayは、マルチテナントService Fabricクラスター上で動作します。周囲を見回すと、顧客データベースはこれらのクラスター上にはホストされていませんでしたが、DB Gatewayはそれでも何らかの方法でそれらに到達する必要がありました。それは、あらゆるCosmos DBクライアントと同様に、ターゲットアカウントのプライマリキーを使用して行われることが判明しました。このキーは、アカウントのデータベースへの完全な読み取り・書き込みアクセスを許可します。 しかし、DB Gatewayは私たちのCosmos DBアカウントのプライマリキーをどのように取得できるのでしょうか? Cosmos Master Key クラスターで利用可能な認証情報を通じて、DB Gatewayは要求されたアカウントのプライマリキーを取得できる署名キーにアクセスしました。すぐに、その署名キーが単一のアカウントにスコープされていないことを発見しました。それはテナント、リージョン、さらにはAPI(SQL、MongoDB、Cassandra、Gremlin)を超えて機能しました。それは、公開されているエンドポイントを通じて、サービス上のあらゆるCosmos DBアカウントのプライマリキーを取得できるプラットフォーム全体のキーでした。私たちはこれをCosmos Master Keyと名付けました。 Config Store - Cosmos DBのアカウントディレクトリ Master KeyはConfig Storeもアンロックしました。これは、アカウント名、サブスクリプションID、テナントID、ネットワーク設定、タグなどを含む、すべてのCosmos DBアカウントのリージョンごとのレジストリです。DB Gatewayは、どのIPがデータベースにアクセスできるかといったアカウント設定のために、これに依存していました。 Config Store自体もCosmos DBデータベースであり、CosmosDBのSQLエンジンの全柔軟性でクエリ可能でした。これは、Cosmos Master Keyがそのプライマリキーを取得できることを意味し、CosmosEscapeを悪用した攻撃者がリージョン内のすべてのアカウントを一覧表示したり、特定のテナントIDでクエリして特定の組織のデータベースを特定したりすることを可能にしました。 影響 Cosmos Master KeyとConfig Storeを組み合わせることで、強力な攻撃チェーンが可能になりました。 ConfigStoreをクエリして、リージョン内のすべてのCosmos DBアカウントを列挙するか、テナントまたはサブスクリプションでフィルタリングして特定の組織をターゲットにします。 Cosmos Master Keyを使用してターゲットのプライマリキーを取得し、すべてのデータベースへの完全な読み取り・書き込みアクセスを許可します。 これは顧客データベースだけでなく、多くのMicrosoftおよびAzureサービスの基盤となるインフラストラクチャとしてCosmos DBが機能しているため、Microsoft自身の内部データベースも同様に公開されていました。 図3: CosmosEscapeの攻撃チェーン CosmosEscapeは、プライベートおよびネットワーク分離されたCosmos DBアカウントにも影響を与えました。DB Gatewayはネットワーク分離の強制を担当しているため、それを侵害するとプライベートデータベースへの直接アクセスが可能になります。さらに、Config Storeへの書き込みアクセスは、攻撃者がネットワーク分離設定を上書きできる可能性を示唆していました。 結論 クラウドプラットフォームはレイヤー構造で構築されています。Cosmos DBのようなサービスはインフラストラクチャ層に位置し、Microsoft Teams、Microsoft Entra ID、Microsoft Copilotなどの上位サービスを支えています。この層での脆弱性は連鎖的に上位に広がり、その上に構築されたサービスを脅かす可能性があります。 マルチテナントクラウドサービスには、テナント制御の実行を中心に少なくとも1つの強力な分離境界が必要です。この境界は、ごくわずかな、厳密に監査された攻撃サーフェスのみを公開する必要があります。その境界内のすべては、テナント制御下にあると見なし、信頼しない必要があります。理想的には、境界はテナントの環境の周りにタイトに引かれるべきです。含まれるリソースが少ないほど、特権認証情報、内部API、およびテナント間パスが手の届かないところにあることを保証しやすくなります。 私たちはこの脆弱性をMicrosoftに責任を持って開示し、Microsoftはそれを完全に修正しました。Microsoftは迅速にホットフィックスを展開し、それ以来、Cosmos DBチームはより優れた、強化されたアーキテクチャへの大規模な移行に昼夜を問わず取り組んでいます。この問題に関する協力と継続的なパートナーシップに、MSRCおよびCosmos DBチームに感謝いたします。 完全なエクスプロイトチェーン、詳細な分析、そしていくつかの驚きについては、Black Hat USAでの私たちの講演「One Key to Rule Them All: Taking Over a Flagship Cloud Service」にご参加ください。 ベンダー声明 Microsoftは、Wizがコーディネイトされた脆弱性開示(CVD)の下で報告した調査結果を調査する機会を得られたことを評価しています。Microsoftはアクセスログの広範なレビューを実施し、研究者のテスト活動以外の不正なアクティビティの証拠は見つからず、顧客データへのアクセスもありませんでした。顧客による対応は不要です。 問題が報告されると、Microsoftのエンジニアリングおよびセキュリティ応答チームは直ちに調査を行い、Azure Cosmos DBのGremlin APIにおけるこの脆弱性の即時緩和策を開発しました。48時間以内に、この攻撃ベクターのエントリーポイントをブロックする緩和策が展開されました。Microsoftは、同様の攻撃ベクターを探すために広範なペネトレーションテストを実施しました。