概要と背景
Google Cloud Platform（GCP）の Cloud Functions
は、イベントトリガー型のサーバーレス関数であり、Hypertext Transfer Protocol（HTTP）リクエストやデータ変更といった特定のイベントに応じて、コードを自動的にスケーリングおよび実行します。Tenable Research が、GCP の Cloud Functions サーバーレス コンピューティング サービスと、Cloud Build 継続的インテグレーション/継続的デリバリーまたはデプロイメント（CI/CD）パイプラインサービスで見つかった脆弱性について解説した記事を公開しました。
Tenable 社の Liv Matan 氏はこう書いています。「GCP ユーザーが Cloud Function を作成または更新すると、複数のステップからなるバックエンドプロセスが起動します。このプロセスではいろいろな処理が行われますが、その 1 つとして、関数のデプロイメントの一環として作成される Cloud Build インスタンスに、デフォルトの Cloud Build サービスアカウントが割り当てられます」。このデフォルトの Cloud Build サービスアカウント（SA）では以前、ユーザーに対して過剰な Cloud Function 権限が付与されていました。クラウド関数を作成または更新する権限を取得した攻撃者は、その関数のデプロイメントプロセスを利用して、デフォルトの Cloud Build サービスアカウントの権限を昇格させたり、より権限の高い SA を割り当てたりする可能性があります。Google 社はその後、Tenable 社の発見を受けて部分的に対処し、デフォルトの Cloud Build サービスアカウントでユーザーに過剰な権限が付与されないようにしました。
Cisco Talos は、Tenable 社の調査に基づき、シスコの Google Cloud Platform（GCP）内で一連の攻撃テストを実施し、お客様の環境に影響を及ぼす可能性のある追加の脅威を特定しました。
Talos は調査の中で、Tenable 社が特定した手法が、他の悪意のある行為を行うために応用できることを確認しました。この手法で使用されている Node Package Manager（NPM）の「package.json」ファイルにさまざまな悪意のあるコンソールコマンドを攻撃者が実装して、環境列挙などの操作を実行する可能性があります。
Talos は調査をさらに進め、Amazon Web Services（AWS）および Microsoft Azure で同様の挙動を再現し、他のクラウドベースの環境において、これらの手法を用いて同様の悪意のある行為を行えるかどうかを確認しました。
調査
前提条件
この攻撃ベクトルを利用するには、一定の前提条件を満たす必要があります。Talos は、GCP 環境内に Debian Linux サーバーを構築し、Node Package Manager（NPM）と Ngrok をインストールしました。ただし、この調査用の仮想マシンは、任意のクラウド環境で作成することができます。
NPM と Ngrok をインストールした後、両ツールが意図したとおりに機能するように設定しました。
NPM と Ngrok を設定した後、クラウド関数から受信したデータを出力するために Python サーバーを作成しました。
NPM、Ngrok、および Python サーバーのセットアップと設定が完了したら、次のステップは NPM パッケージの作成と修正です。
その後、package.json ファイルの内容を次のコードに置き換えました。
必要なファイルをすべて作成および設定した後の最後のステップは、関数のデプロイによって出力されるデータを視覚的に表示するための環境をセットアップすることです。これを実現するために、先ほど作成した Ngrok サーバーと Python サーバーの両方を起動しました。
Tenable 社の記事で説明されている GCP の挙動を再現するために、Function Build および Cloud Build の権限を持つサービスアカウント（SA）を作成/更新しました。この SA は、特権アクセスでコードを実行できるように、GCP の Cloud Run Function に割り当てられました。
サーバーとサービスアカウントが稼働し、データの受信と出力を行うように設定されると、挙動のエミュレーションを開始できます。
エミュレーション
package.json ファイルをビルド関数で利用できるように構成した後、Tenable 社の調査記事で説明されている手法のエミュレーションを開始しました。
再現作業の最初のステップは、GCP 関数の設定ミスを利用してデフォルトの Cloud Build サービスアカウントトークンを抽出することでした。このプロセスを開始するために、仮想マシン上の「悪意のある」package.json ファイルを更新し、Tenable 社が使用したものと類似のコードが含まれるようにします。
目的に合うように package.json ファイルを修正したら、パブリック NPM レジストリに公開する必要があります。これを行うために、次のコマンドを実行しました。
package.json ファイルを NPM パブリックレジストリにアップロードしたら、GCP の Cloud Run Function をデプロイし、package.json に組み込んだコードが実行されるようにします。これを行うには、GCP Cloud Run Functions ページにアクセスし、Cloud Run Function を選択または作成し、Cloud Build 権限を持つサービスアカウントが割り当てられていることを確認する必要があります。
図 1. 割り当てられたサービスアカウントを表示する Google Cloud Run Function
GCP の Cloud Run Function を作成するか、既存の Cloud Run Function を選択すると、その関数のソースページに移動します。ここで package.json ファイルを修正し、NPM にアップロードした悪意のあるパッケージがインストールされるようにしました。
図 2. Google Cloud Run Function のソースページ
package.json ファイルを正しい NPM パッケージ名とバージョンで更新した後、[Deploy] または [Save and Redeploy] を選択し、ビルドプロセスを開始しました。このプロセス中に、関数は要求されたデータを Ngrok サーバーに送信し、そのデータが Python サーバー上に出力されました。
Talos は、Google 社の対応とパッチ適用により、この手法を用いて GCP サービスアカウントのアクセストークンを持ち出すことは不可能になったことを確認しました。さらなる検証のため、NPM にアップロードした package.json に組み込んだのと同じコマンドを別の仮想マシンから実行してみました。コマンドは正常に実行されましたが、権限付きサービスアカウントトークンを取得することはできず、この特定の手法がパッチ適用によって使用できなくなったことが確認されました。
独自調査
Cisco Talos の調査では、Tenable 社による元々の挙動の概念を拡張し、それぞれのクラウドサービスに応じた変更を加えることで、他のクラウド環境にも応用しました。AWS Lambda と Azure Functions は、ユーザーがサーバーのプロビジョニングや管理をしなくてもコードを実行できるサーバーレス コンピューティング サービスです。Node.js 20.x ランタイムを使用して Lambda 関数または Azure 関数を作成すると、NPM のパブリックリポジトリにアップロードされている悪意のあるパッケージを実行するように依存関係を設定した package.json ファイルを作成できます。これらの悪意のあるパッケージには、有益な列挙情報を攻撃者に提供する有害なコンソールコマンドが含まれている可能性があります。
この特定の手法を用いた攻撃活動はもはや実行できませんが、他のコマンドを使用して、有益な列挙機能を攻撃者に提供できることが実証されています。これらのコマンドは、GCP の Cloud Build Function だけでなく、AWS Lambda や Azure Functions といったクラウドプラットフォームでも使用できます。
ここからは、攻撃者がこの方法を使用して実行できる列挙の種類の例をいくつか紹介します。
ICMP 検出
Internet Control Message Protocol（ICMP）検出は、ネットワークデバイスとその構成に関する情報を収集するために使用されます。ICMP 応答を分析することで、ルータやゲートウェイの存在、デバイス間の経路など、ネットワークの構造を推測することができます。この情報は、攻撃計画を立てるうえで非常に重要になります。
.dockerenv の存在
.dockerenv ファイルが検出されたということは、プロセスが Docker コンテナ内で実行されているということです。このファイルの有無を確認することで、攻撃者は自分が Docker 環境内で活動しているかどうかを確認できます。この情報は、ツールや手法の選択に影響を与える可能性があります。なぜなら、コンテナはホストシステムとは異なるセキュリティ境界を持つことが多いからです。
CPU スケジューリング
CPU スケジューリングの列挙により、プロセス識別子（PID）1 のプロセス（通常はコンテナ環境内の init システムまたはメインプロセス）の詳細なスケジューリング情報とステータス情報が得られます。攻撃者は、systemd や sysvinit など、使用されている init システムを特定できます。この情報は、システムの構成を把握し、特定の init システムに関連する潜在的脆弱性を特定する手がかりになります。
コントロール グループ コンテナ ID
コントロール グループ コンテナ ID を列挙すると、現在のマウントポイントに関する詳細な情報を得ることができます。攻撃者はこの情報を使用して、データ持ち出しの対象になり得る重要なファイルシステムや機密性の高いファイルシステムを特定できます。マウントオプションを調べることで、悪意のあるバイナリが導入される可能性のあるディレクトリに exec 権限付きでマウントされているファイルシステムのような、安全でない設定を見つけることができます。コンテナ化された環境においては、マウント名前空間を理解することがコンテナからの脱出技術の開発に役立ち、それによって攻撃者はコンテナを抜け出してホストシステムにアクセスできるようになります。
コントロール グループ コンテナ ID プレーンテキスト 1 とコントロール グループ コンテナ ID プレーンテキスト 2
初期サーバーの概要
初期サーバーの概要の列挙では、以下のコマンドを組み合わせることで、システムのカーネル、アーキテクチャ、ディストリビューションに関する包括的な情報が得られます。これらの情報は、環境を理解し、潜在的なエクスプロイトを計画するうえで非常に重要です。多くの脆弱性はバージョン固有のものなので、正確な OS とカーネルバージョンが分かれば、攻撃者は最適なエクスプロイトを選択できます。
ユーザーと権限の列挙
ユーザーおよび権限関連の次のコマンドは、ユーザーアカウントや権限、グループメンバーシップに関する情報を提供します。これらの情報は、システム内での特権昇格やラテラルムーブメントを計画するうえで重要です。
ネットワークの検出
ネットワークおよび検出関連の次のコマンドは、システムの動作環境やネットワーク構成に関する詳細な情報を収集するのに役立ちます。これらの情報は、脆弱性の特定や攻撃の計画に利用される可能性があります。
詳細なシステムコマンド
「cat /etc/os-release」コマンドを実行すると、オペレーティングシステムのディストリビューションとバージョンが表示されます。正確な OS 情報を把握することで、攻撃者は固有の脆弱性を特定し、標的の環境に合わせて攻撃方法を調整することができます。
ユーザー関連コマンド
「/etc/shadow」ファイルには、ユーザーアカウントのハッシュ化されたパスワードが含まれており、これにアクセスされると、パスワードが解読されてシステムへのアクセス権が昇格される可能性があります。
AWS Lambda 関数
以下の例は、Google Cloud Platform（GCP）環境で Talos が使用したコマンド（これまでに説明してきたもの）を、Lambda 関数を用いて Amazon Web Services（AWS）環境で実行した結果を示したものです。これは、Tenable 社のラボで使用された手法が AWS などの他のクラウドベースの環境にも応用可能であることを示しています。
Azure Functions
以下の例は、AWS Lambda 関数で実行したのと同じプロセスを、今度は Azure 環境内で Azure Functions を用いて実行した結果です。これは、この手法がさまざまなクラウドベースの環境で応用可能であることをさらに裏付けるものです。
まとめと防御策の要点
Google 社の対応
Tenable 社の記事で説明されているように、Google 社は調査結果を受けて修正パッチを作成しました。このアップデートにより、Cloud Build のデフォルトの挙動と、デフォルトの Cloud Build SA が変更されました。さらに、新しい組織ポリシーがリリースされ、Cloud Build がデフォルトで使用する SA を完全に制御できるようになりました。ただし、Google 社がこの対応を取ったとはいえ、Cloud Build サービスでは依然として権限の低いコマンドを実行できるため、環境の列挙手段として利用される可能性があります。
緩和策の要点
同様の攻撃から環境を保護するための最も効果的な緩和策は、クラウド環境内のすべての SA に最小権限の原則が適用されるよう徹底し、かつレガシークラウド SA が使用されていないことを確認することです。すべてのクラウドサービスと依存関係に最新のセキュリティパッチが適用されていることを確認し、レガシー SA が存在する場合は、最小権限の SA に置き換えてください。
さらに、Cloud Functions にアクセスできるユーザーには、関数内で使用されているサービスに対する IAM 権限を付与しないようにしてください。
脅威ハンティングの推奨事項
- SA 権限の監査とモニタリング：特にデフォルトの Cloud Build SA に注目し、SA 権限を定期的に監査およびモニタリングします。SA の運用に必須ではない過剰な権限はすべて削除し、最小権限の原則を徹底してください。
- Cloud Functions のアラート設定：Cloud Functions の不審または不正な作成や変更が行われた場合に通知するアラートを設定し、攻撃者による悪意のある行為を特定します。関数のデプロイメントを悪用して、特権昇格を狙っている可能性があります。
- ネットワークトラフィックの検査：ネットワークトラフィックを分析し、データの持ち出しを示唆するような異常なパターンや接続がないか確認します。Ngrok などのトンネリングサービスを使用している、未知または許可されていない外部エンドポイントにデータが送信されていないか注意してください。
- NPM パッケージの完全性の検証：Cloud Functions 内で使用される NPM パッケージの完全性と真正性を確認します。環境の列挙やその他の悪意のある行為を容易にする可能性のある、package.json ファイルに埋め込まれた悪意のあるスクリプトの実行を防止します。
- 環境列挙の検出：ICMP 検出やシステム情報の収集など、環境列挙の兆候を検出して対応します。
本稿は 2025 年 5 月 20 日にTalos Group
Authors