パブリッククラウド攻撃と防御シリーズ - クラウドサービスの活用

1. はじめに

近年、クラウドコンピューティングモデルは業界で徐々に認知され、受け入れられるようになりました。ビジネスをクラウドに移行する企業が増えており、パブリッククラウド、プライベートクラウド、ハイブリッドクラウド、コミュニティクラウドなど、ビジネスをクラウドに移行するモデルは多岐にわたります。中でもパブリッククラウドは、低コストや柔軟性などの利点から中小企業に好まれています。企業は一定の料金を負担するだけで自社のビジネスに集中でき、基盤となる設備のインストールとメンテナンスはクラウドサービスプロバイダーに任せることができます。しかし、現在のネットワークセキュリティの状況は厳しく、ビジネスセキュリティも企業が考慮しなければならない重要なポイントとなっています。

では、パブリッククラウドはどの程度安全なのでしょうか?攻撃者の観点から見ると、「クラウドに対する攻撃と防御：クラウド向けレッドチーム」[1]の考え方を参考にすると、パブリッククラウド環境が直面する脅威は主に2つのカテゴリに分けられます。

パブリッククラウド上のテナントの安全でないアプリケーションとサービス構成を侵害ポイントとして悪用する
パブリッククラウドサービスの本質的な問題を突破口として利用する

この記事では、主に 2 番目のタイプ、つまりクラウドベンダーが提供するクラウドサービスを突破口として利用し、最終的にパブリッククラウド環境の崩壊につながる攻撃技術について説明します。テクノロジー自体はプラットフォームや環境によって制限されるかもしれませんが、そこに含まれるアイデアやテクニックは学び、考える価値があります。関連する攻撃手法を理解した後、パブリッククラウドのセキュリティにはクラウドサービスプロバイダーとクラウドテナントによる共同メンテナンスが必要であり、どちらも不可欠であることを読者が理解してくれることを願っています。

この記事で取り上げる技術は教育および研究目的のみに使用され、違法な目的での使用は禁止されています。

II.背景

パブリッククラウドベンダーは、コンピューティング、コンテナー、データベース、ストレージ、サーバーレスなどのカテゴリをカバーする多種多様なクラウドサービスを提供しています。クラウドベンダーによって提供されるクラウドサービスも異なります。これらのクラウドサービスの一部は、クラウド化されて顧客に提供される従来の製品である可能性があることに留意してください。たとえば、データベース製品の場合、ユーザーに提供されるサービスは最終的にはほぼ同じですが、クラウドベンダーによってクラウド環境に適応するために二次的な変更が製品に行われることがあります。これはユーザーにはわかりませんが、攻撃者にとっては突破口となる可能性があります。次に、いくつかの事例を用いて、さまざまなクラウドベンダーが提供するクラウドサービスの実際のリスクを説明します (記事で言及されているリスクはすべて公開され、修正されています)。

3. ケーススタディ

3.1 ケース1 — Google Cloud サービスの脆弱性

Google Cloud SQL は、ユーザーが自分で管理することなく SQL Server、PostgreSQL、または MySQL サーバーをデプロイできる、完全に管理されたリレーショナルデータベースサービスです。これらの Cloud SQL データベースには、特定のコマンドラインツールまたはアプリケーションを通じてアクセスできます。パブリッククラウド環境における複数のテナントの分離とセキュリティを確保するために、クラウドベンダーはユーザー権限とアプリケーション権限を制限し、制御不能な分離リスクを防止します。ただし、権限制御は簡単な作業ではありません。一部の研究者は、Google Cloud の MySQL、PostgreSQL、Google Guest Agent に関連する脆弱性を発見しました。これらの脆弱性を利用すると、コマンドを実行してコンテナを脱出することができ、他のテナントのクラウド環境が脅かされる可能性があります。以下では、脆弱性悪用チェーンについて簡単に紹介します。

CloudMySQL コマンド実行 + コンテナエスケープ

この脆弱性は研究者のエゼキエル・ペレイラ[2]によって発見されました。 MySQL では、SUPER 権限はシステム管理関連のタスクに使用され、FILE 権限は MySQL デーモンを実行しているサーバー上のファイルの読み取りと書き込みに使用されます。これらの権限を取得すると、サーバーに簡単に損害を与えることができるため、通常はデータベースサービスのみを利用するユーザーには上記の権限を付与しないでください。 Google Cloud コンソールインターフェースで MySQL インスタンスを管理しているときに、研究者はバケットからデータベースをインポートおよびエクスポートする機能を発見しました。この機能は、図 1 に示すように、カスタム SQL クエリをサポートします。

図1 MySQLエクスポートデータベース機能インターフェース

テストの結果、研究者らは 2 つの悪用可能なポイントを発見しました。

エクスポートのために MySQL に接続したユーザーには FILE 権限があり、データをバケットにエクスポートする前に '/mysql/tmp' ディレクトリに一時的に保存できます。
エクスポートツールを実行すると、API は実際に何らかの方法で mysqldump ツールを呼び出し、データベースをパラメーターとして渡します。他のパラメータも渡すことができます。

調査の結果、mysqldump には --plugin-dir と --default-auth という、悪用される可能性のある 2 つのパラメータがあることが判明しました。 --plugin-dir パラメータを使用すると、クライアントプラグインが保存されるディレクトリを渡すことができ、--default-auth は認証プラグインを指定します。これら 2 つの悪用可能なポイントを組み合わせると、次の攻撃チェーンが構築されます。

リバウンドシェル関数を使用して evil_plugin.so プラグインを作成し、それをデータベースに挿入してバケットにアップロードします。次に、MySQL の機能を使用してバケットからデータをエクスポートし、SQL クエリステートメントを「SELECT * FROM data INTO DUMPFILE '/mysql/tmp/evil_plugin.so' #」にカスタマイズして、図 2 に示すようにデータパケットを変更します。

図2 エクスポートされたデータベースパッケージを変更する

最後に、データベースサービスが配置されているコンテナーのシェルが正常に再バインドされます。

コンテナからの脱出

情報を収集した結果、Google Cloud SQL データベースサービスを実行しているコンテナは特権コンテナではないことが判明しました。 ifconfig を実行した結果を図 3 に示します。

図3 ifconfigの結果

これは、コンテナーがホストのネット名前空間を共有していることを示します。この場合、ホストのネットワークカードで送受信されるネットワークトラフィックが傍受される可能性があります。

Google が提供するパブリックイメージを使用して仮想マシンを起動すると、システムによって仮想マシンインスタンスに google-guest-agent が自動的にインストールされます。エージェントの役割は、メタデータの変更を監視することです。メタデータの 1 つが SSH 公開キーです。メタデータ内に新しい SSH 公開鍵が見つかった場合、google-guest-agent は公開鍵をユーザーの .authorized_key ファイルに書き込み、新しいユーザーを作成して、必要に応じて sudoer として追加します。研究者らは、google-guest-agentエージェントの機能とホストのネット名前空間を共有するコンテナの特性とを組み合わせて、カスタマイズされたツールrshijack[3]を使用してトラフィックをハイジャックし、仮想マシン上に指定されたSSHユーザーを作成し、仮想マシンに接続してコンテナから脱出することに成功しました。

CloudPostgreSQL 権限昇格 + コンテナからの脱出

最も人気のあるデータベースの 1 つである PostgreSQL も、パブリッククラウドベンダーによって変革され、サービスを提供しています。 PostgreSQL の権限モデルは非常に制限されており、基本的にユーザーは特定の管理機能しか使用できないため、クラウドベンダーは権限モデルを変換して、ユーザーが特定の管理機能を使用できることを保証しながら、一部の安全でない操作を制限する必要があります。クラウドベンダーによって変換方法は異なります。拡張機能やカスタム構成を導入することで変更を加える場合もあれば、PostgreSQL エンジンコードを変更することで変更を加える場合もあります。しかし、このような変革は予期せぬセキュリティ問題を引き起こす可能性があります。

Wiz Researchは、複数のパブリッククラウドベンダーのPostgreSQLに脆弱性を発見しました[4]。この脆弱性は、特にGoogleパブリッククラウド環境で権限を昇格するために使用できます。データベースサービスを使用してコンテナシェルを取得すると、前述の google-guest-agent トラフィックをハイジャックする方法と組み合わせてコンテナを脱出することができ、パブリッククラウド環境のセキュリティが脅かされる可能性があります。

Google が PostgreSQL サービスを提供するために使用するアカウントは postgres であり、これは cloudsqlsuperuser ロールの一部です。公式ドキュメントを見ると、ロールの権限は図 4 に示されています。

図4 Google cloudsqlsuperuser ロールの権限の説明

このロールは PostgreSQL のデフォルトの動作ではなく、Google によって変更されています。ドキュメントを観察すると、このロールにより、テーブルの所有権をデータベース内の任意のユーザーとロールに変更できることがわかります。本来の目的は、低い権限を持つユーザーに高い権限を持つ機能を与えることですが、攻撃者に悪用される機会を与えてしまいます。

PostgreSQL の ALTER TABLE とインデックス関数の組み合わせ

PostgreSQL の INSERT/UPDATE/ANALYZE コマンドがインデックス関数を持つテーブルで実行される場合、関数はコマンドの一部として呼び出され、テーブル所有者の権限で呼び出されることに注意してください。

図5: インデックス関数実行の概略図

したがって、次の攻撃チェーンを構築して悪用することができます。

新しいテーブルを作成する
テーブルに任意のコンテンツを挿入する
テーブルに悪意のあるインデックス関数を作成する（リバウンドシェル関数を含む悪意のあるコードを含む）
テーブルの所有者を cloudsqladmin (Google Cloud Platform のスーパーユーザーロール。CloudSQL データベースの保守と管理にのみ使用されます) に変更します。
テーブルに対してANALYZEコマンドを実行し、インデックス関数がcloudsqladmin権限で呼び出され、悪意のあるコードが実行される

最後に、コンテナのシェルが正常に取得され、権限は postgres ユーザーになります。次に、書き込み権限を持つディレクトリ内に、ルートアカウントが所有するファイルが見つかりました。シンボリックリンク攻撃は、権限をルートに昇格するために使用されました (この記事では詳細には触れませんが、興味のある方は元の記事をお読みください)。最終的に、前述の google-guest-agent トラフィックをハイジャックすることでコンテナが脱出され、ホスト上の SSH ログイン権限が取得されました。

3.2 ケース2——Microsoft Azureクラウドサービスの脆弱性

AzurePostgreSQL 権限昇格の脆弱性

Coogle と同様に、Microsoft Azure も PostgreSQL クラウドサービスを提供する際にエンジンに二次的な変更を加えましたが、Azure には PostgreSQL の権限管理が欠けています。テストの結果、Azure PostgreSQL サービスを使用しているユーザーに CREATEROLE 権限が付与されていることが判明しました。

CREATEROLE は、ユーザーが新しいユーザーを作成し、特定のロールに関連付けることができる非常に強力な権限です。 PostgreSQL には、pg_read_server_files、pg_write_server_files、pg_execute_server_program などの強力な組み込みロールがいくつかあります。これらのロールの権限は次のとおりです。

pg_read_server_files - ユーザーにファイルシステムから任意のファイルを読み取る権限を与えます。

pg_write_server_files - ユーザーにファイルシステムに任意のファイルを書き込む機能を提供します。

pg_execute_server_program - 最も強力なロールであり、ユーザーにオペレーティングシステムレベルで任意のコマンドを実行する権限を与えます。

PostgreSQL の公式ドキュメントでは、CREATEROLE ロールはほぼ「スーパーユーザー」であると警告されています。しかし、Azure はこのロールを導入する際に変更や制限を加えなかったため、ユーザーは PostgreSQL の COPY 機能と組み合わせてシステム上で任意のコマンドを実行し、コンテナーのアクセス許可を取得できるようになりました。

Service Fabric 権限昇格の脆弱性

2022 年 6 月、Unit 42 研究所の研究者は、攻撃者がコンテナ内のホストノードの権限をルート権限に昇格できる Microsoft Service Fabric の脆弱性 (CVE-2022-30137) を公開しました。悪用の閾値は低く、被害は大きい。

Server Fabric は、ユーザーがスケーラブルで信頼性の高いマイクロサービスとコンテナを簡単にパッケージ化、展開、管理できるようにする分散システムプラットフォームです。製品の位置付けは Kubernetes と似ていますが、異なります。 Service Fabric は現在、Azure SQL Database、Azure Cosmos DB、Cortana、Microsoft Power BI、および多くの Azure コアサービスを含む多くの Microsoft サービスで使用されています。

Service Fabric クラスターは多数のノードで構成されます。各ノードはコンテナエンジンを実行して、必要なコンテナ化されたアプリケーションを実行します。各ノードで実行されているコンポーネントは、図 6 に大まかに示されています。

図 6 Service Fabric Linux ノードの例

Service Fabric は、コンテナーとしてのアプリケーションのデプロイをサポートしています。各コンテナの初期化中に、新しいログディレクトリが作成され、読み取り/書き込み権限で各コンテナにロードされます。すべてのコンテナに対応するディレクトリは、各ノード上の同じパスに集中しています。たとえば、Azure Service Fabric 製品では、これらのディレクトリは /mnt/sfroot/log/Containers にあります。

データ収集エージェント (DCA) は、Service Fabric クラスター内のコンポーネントであり、後続の処理のためにこれらのディレクトリからログを収集する役割を担います。これらのディレクトリにアクセスするには高い権限が必要なので、このコンポーネントは各ノードで root として実行されます。 DCA の古いソースコードを詳しく調べたところ、任意の書き込みに対して関数 GetIndex (PersistedIndex.cs:48) で潜在的な競合状態が発生する可能性があることがわかりました。攻撃者はシンボリックリンクを作成し、ノードファイルシステム内のファイルを悪意のあるコンテンツで上書きして、最終的にノード上でのコード実行権限を取得する可能性があります。攻撃チェーンは、図 7 に大まかに示されています。

図7 FabricScape攻撃チェーン

任意の書き込みを引き起こす GetIndex 競合状態と、DCA がホスト上で root として実行されるという事実を利用して、ホスト上の /etc/environment ファイルを上書きするシンボリックリンクが作成されます。
ServiceFabric ノードでデフォルトで実行される CronJob の特性を利用して、ジョブの実行時に /etc/environment ファイルをインポートします。
Cronjob 起動プロセスが初期化されると、/etc/environment ファイル内の LD_PRELOAD 環境変数がロードされ、カスタム共有オブジェクトがポイントされます。
最後に、共有オブジェクト内のリバウンドシェルコードが正常に実行され、ノードのルート権限が取得されます。
ServiceFabric クラスター管理ツール sfctl に必要な証明書は、/var/lib/waagent/ ディレクトリにあります。図 8 に示すように、sfctl ツールを使用してクラスター全体を制御します。

図8 sfctlツールの実行例

3.3 ケース3 - AWS クラウドサービスの脆弱性

Log4Shell ホットパッチコンテナのエスケープと権限昇格の脆弱性

Log4Shell (CVE-2021-44228) は、2021 年の最も深刻な脆弱性の 1 つです。ユーザーがこの脆弱性から防御できるように、AWS はさまざまな環境向けにいくつかのホットパッチソリューションをオープンソース化しました。ホットパッチとは、脆弱性のある実行中のアプリケーションに修正プログラムを挿入するプロセスです。これは、アプリケーションの新しい修正バージョンが展開されるまでの短期的な解決策として意図されています。

しかし、研究者らは、これらのパッチを悪用してコンテナから脱出し、権限を昇格できることを発見した[5]。コンテナ内の Java プロセスにパッチを適用するために、hotpatch はコンテナの「java」バイナリを 2 回呼び出します。1 回は Java バージョンを取得するため、もう 1 回は hotpatch を挿入するためです。問題は、コンテナバイナリを呼び出すときに、適切にコンテナ化されていないにもかかわらず、ホストのルートユーザーとして実行される場合に発生します。したがって、攻撃者は悪意のあるコンテナ内で「java」という名前の悪意のあるバイナリを実行し、HotPatch がそれを認識して高い権限で呼び出すことができるようになり、最終的にコンテナとホストから脱出することができます。

ホットパッチサービスは、コンテナに加えて、同様の方法でホストプロセスにもパッチを適用します。したがって、攻撃者は、「java」という名前の悪意のあるバイナリファイルを作成して実行することで、通常のプロセス権限からルート権限に昇格することもできます。

IV.要約と考察

この記事で紹介した事例から、パブリッククラウドは便利なクラウドサービスを提供する一方で、予期せぬリスクをもたらす可能性もあることがわかります。 AWS や Google のような大手ベンダーであっても、クラウドサービスの設計と管理でミスを犯し、攻撃者に悪用される機会を与えてしまう可能性があります。

攻撃者の視点から見ると、PostgreSQL などの従来の製品がクラウドに移行した後に不適切な権限管理が行われる事例から学び、クラウドサービスにおける「弱点」を深く掘り下げ、クラウドに移行した後に脆弱性が改善されたかどうか、改善ソリューションにも一定の活用ポイントがあるかどうかを分析し、特に公式ドキュメントで促されているリスク警告ポイントに注意を払うことができます。

防御側の観点から見ると、攻撃者がパブリッククラウドサービスを悪用する場合、通常はコードロジックを確認できず、ブラックボックス方式でしか攻撃テストを実行できません。したがって、パブリッククラウドベンダーは、パブリッククラウド環境における侵入検知システムを強化する必要があります。ケース 1 の研究者は、MySQL と PostgreSQL を使用してホストマシンに逃げた直後に Google の従業員に発見され、連絡を受けました。他のクラウドベンダーも同様の対応を取るべきです。ハッカーの「主戦場」であるパブリッククラウド環境の防御能力は、リアルタイムで強化される必要がある。