クラウドにおけるサーバーレス トークン: エクスプロイト攻撃と検出

エグゼクティブ サマリー

本記事では、主要なクラウド プラットフォームにおけるサーバーレス認証の仕組みとセキュリティ上の意味について概説します。攻撃者は、アプリケーション開発者が安全でないコードをデプロイし、クラウド機能を誤って設定した結果生じる脆弱性をエクスプロイトすることを目的に、サーバーレス機能をその標的にしています。これらの弱点のエクスプロイトに成功すると、攻撃者は認証情報を入手することができ、それを悪用することができます。

サーバーレス コンピューティングの機能は、多くの場合、認証トークンを使用してクラウド サービスやリソースに一時的にアクセスするためのクラウドIDと関連付けられています。これらのトークンが流出すると、クラウド環境がセキュリティ リスクにさらされる可能性があります。

Amazon Web Services (AWS) LambdaをはじめAzure FunctionsやGoogle Cloud Run Functionsなどはすべて、認証情報を利用するサーバーレス プラットフォームと関数の例です。これらの認証情報にはそれぞれ、AWSのIDおよびアクセス管理(IAM)ロール、AzureのマネージドID、Google Cloud Platform（GCP）のサービス アカウント トークンが含まれます。

これらのサービスがどのように動作するかを理解することで、トークンの公開を回避する効果的な戦略を実装したり、クラウド環境の侵害につながる公開されたトークンのエクスプロイトを検出したりすることが可能になります。このような侵害には、特権の昇格、環境内での悪意のある持続、正当なIDのみがアクセスできるはずの機密情報の流出が伴います。

パロアルトネットワークスのお客様は、弊社のCortex製品ラインをご活用いただくことで、本記事で取り上げる脅威からより確実に保護することができます。情報漏えいの可能性がある場合、または緊急の案件がある場合は、Unit 42インシデント レスポンス チームまでご連絡ください。

はじめに

サーバーレス コンピューティングには、AWS (Lambda)、Azure (Functions)、Google Cloud (Functions)などのプロバイダーがインフラ、スケーリング、メンテナンスを管理するクラウドモデルがあります。このモデルによって、組織とその開発者はコードのみに集中することができ、クラウド プロバイダーはバックエンドのタスクを処理します。

イベント ドリブンで動作するサーバーレス関数は、HTTPリクエストやデータベースの変更、スケジュールされたイベントなどのトリガーに応答して実行されます。関数サービスの自動スケーリングは、需要に合わせてリソースを調整し、クラウド プロバイダーは実行時間と使用リソースに対してのみ課金することで、コスト効率を確保することができるものです。

サーバーレス コンピューティングは開発とデプロイを簡素化する一方で、これらのサービスに関連する潜在的なリスクを理解することが重要とされています。これらのリスクの一部は、開発者がサーバーレス関数にアイデンティティを割り当てることができ、それらのアイデンティティは、関数内で実行されるコードからアクセス可能な認証情報セットとして明示されるという事実から生じます。これらの認証情報は、クラウド操作を実行するための認証と承認に使用されます。

認証情報には、その使用を規定する一連のパーミッションが適用されます。関数に関連付けられているIDに関連付けられた権限に応じて、これらの認証情報はクラウド リソースや機密データへのアクセスを可能にします。

攻撃者がサーバーレス関数を狙う理由:

• サーバーレス関数は、安全でない開発手法のために、リモート コード実行(RCE)やサーバー サイド リクエスト フォージェリ(SSRF)攻撃に対してしばし脆弱とされます
• サーバーレス関数は、設計上または設定ミスにより一般に公開されたり、外部ソースからの入力を処理したりすることが多いです
• 攻撃者は、サーバレス トークンを悪用して、重要なインフラやデータを危険にさらす可能性のある不正な読み取り/書き込みアクセスを取得することができます

サーバーレス関数を使用する場合、アプリケーション開発者が安全でないコードをクラウド機能にデプロイする際のリスクを考慮し、これらの関数を標的とする脅威を理解することが重要です。

主要クラウド プラットフォームにおけるサーバーレス認証の仕組み

サーバーレス アプローチを使えば、アプリケーションはオンデマンドで関数を実行することでデプロイされます。このアプローチの主な利点は、アプリケーションや特定のコンポーネントを必要に応じて実行できるため、継続的に実行する環境が不要になることです。

各主要クラウドプロバイダーは、サーバーレス関数に関して、以下のような同様のコンセプトを共有しています。

• 複数のコード言語に対応
• フルマネージド アーキテクチャのため、SSHアクセスがない
• ロール、サービス アカウント、または管理されたIDを使用した、リソースへのアクセスの安全な管理

AWS Lambda

AWSのIAMサービスは、ユーザー、権限、グループ、ロールの作成と管理を可能にするものです。このサービスは、AWSアカウントとサービスに対するアイデンティティとそのアクセス レベルを管理し、AWSアカウント内のさまざまな機能を制御する役割を担います。

サーバーレス関数は、デフォルトのパーミッションを持たないLambdaロールを使用するため、パーミッションを管理し、他のAWSサービスへのアクセスを保護するには、IAMポリシーを使用する必要があります。

権限管理の簡素化を目的に、AWSはマネージド ポリシー(AWSLambdaBasicExecutionRole)のような)を提供しており、開発者は基本的な関数を素早く有効にするために、これらのロールにアタッチすることが多いです。

IAMロールがLambda関数に関連付けられると、AWSセキュリティ トークンサービス(STS)が自動的に 一時的なセキュリティ認証情報を自動的に生成します。

これは長期間のハードコードされた認証情報に関連するリスクなしに、実行時に認証情報にアクセスする安全な方法です。

これらの認証情報は、ロールに関連するアクセス ポリシーで定義されたパーミッションにスコープされます。これには、アクセス キーID、シークレット アクセス キー、セッ ション トークンが含まれます。

実行時に、Lambdaランタイム サービスは関数の実行環境にロール認証情報をロードし、AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKENなどの環境変数として保存します。これらの変数は実行時に関数のコードからアクセスが可能であり、これにより関数が他のAWSサービスと安全にやり取りすることができます。

Google Cloud Functions

Google Cloud Functionsは、サービス アカウントトークンを使用して、他のGoogle Cloudサービスへのアクセスを認証・認可します。サービス アカウントは、プロジェクトに関連づけられ、個々のユーザーではなく、人間以外のアイデンティティを表す、特別なGoogleアカウントです。

クラウド関数をデプロイする際、開発者はカスタムサービス アカウント、またはデフォルトのサービス アカウントに関数をアタッチすることができます。カスタム サービス アカウントを使用する場合、開発者は特定のIAMロールを割り当てて、その機能がタスクを実行するために必要な正確な権限を定義することができます。

デフォルトのサービス アカウントは ユーザー管理アカウントユーザが特定のサービスを有効にするとGoogle Cloudが自動的に作成するユーザ管理アカウントです。デフォルトでは、Google Cloud Functionsは以下の通り世代によって異なるサービス アカウントが使用されます。

• 第一世代のCloud Run関数: App Engineのデフォルトのサービス アカウント(<project_id>@appspot.gserviceaccount.com )
• 第二世代のCloud Run関数: Default Computeサービス アカウント(<project_number>-compute@developer.gserviceaccount.com)

これらのデフォルトのサービス アカウントには、開発者が組織なしでGCPにオンボーディングする際にエディタ権限が付与され、プロジェクト内のリソースを作成、変更、削除することができます。しかし、GCP組織下のプロジェクトでは、デフォルトのサービス アカウントは権限なしで作成されます。このような場合、ロールに割り当てられた明示的に許可されたアクションしか実行できません。

GCP関数はサーバーレス環境で動作しますが、関数に関連付けられた認証情報へのアクセスに関しては、実行時にインスタンス メタデータ サーバー(IMDS)からサービス アカウント トークンを取得することで、仮想マシン(VM)インスタンスなどの従来のサーバーと同様に動作します。hxxp://metadata.google[.]internal/にあるIMDSは、関数の関連するサービス アカウントのための短期間のアクセストークンを提供します。これらのトークンによって、関数によるGCPサービスに対する認証が可能になります。

Azure Functions

AzureマネージドIDは、Azureリソースがハードコードされた認証情報を必要とすることなく、他のAzureサービスに対して認証し、相互作用するためのセキュアでシームレスな方法を提供するものです。AWSやGCPの関数サービスと同じように、これらのIDはコード内の認証情報管理に伴うリスクを排除します。

システムに割り当てられた管理対象IDは1つのリソースに関連付けられ、リソースが削除されると自動的に削除されます。一方、ユーザが割り当てた管理IDは、複数のサービスに割り当てることができる独立したリソースであり、共有認証シナリオに対してより柔軟性を持つことができます。

マネージドIDがアタッチされたAzure Functionは、そのマネージドIDトークンを使用してAzureリソースを認証する必要があります。ステップ バイ ステップの認証プロセスは以下の通りです。

• 関数は、IDENTITY_ENDPOINTとIDENTITY_HEADERの値を取得するために環境変数を照会します。
  • IDENTITY_ENDPOINT: 環境変数には、Azureが提供するローカルのマネージドIDエンドポイントのアドレスが格納されます。これはアプリがトークンをリクエストできるローカルURLです。
  • IDENTITY_HEADER: ローカルのマネージド ID エンドポイントに問い合わせを行う際に必要なパラメータです。このヘッダーはSSRF攻撃を軽減するために使用されます。
• この関数は、HTTPヘッダーとしてIDENTITY_HEADERを含むHTTP GETリクエストをローカルの管理対象IDエンドポイントに送信します(リクエスト構造の詳細については 取得中のAzureのドキュメントを参照してください)。
• Microsoft Entra ID (旧 Azure Active Directory)が機能のIDを検証し、ターゲット リソース専用にスコープされた一時的なOAuth 2.0トークンを発行します。
• この関数は、発行されたトークンをAzureリソースへのリクエストに含めます(例: Azure Key Vault、ストレージアカウント)。
• Azureリソースはトークンを検証し、ロールベースのアクセス制御、またはリソース固有のアクセスポリシーを使用して、関数の権限をチェックします。

認可された場合、リソースは要求された操作を実行するためのアクセスを許可します。これにより、コードにハードコードされた秘密を使用する必要なく、安全でシームレスな認証が保証されます。

トークン窃取の攻撃ベクトル

このセクションでは、サーバーレス関数の使用に伴うリスクと脅威について説明します。関数を開発・設定する際、アプリケーション開発者は、SSRFやRCEのような攻撃に対して、その関数を確実に保護する必要があります。このようなセキュリティがない場合、攻撃者はSSRFに脆弱なサーバーレス関数を操作し、その関数が内部サービスに不正なリクエストを送信する可能性があるためです。これはアクセス トークン、内部データベース コンテンツ、サービス設定など、システム内の機密情報への意図しないアクセスや暴露につながる可能性があります。このようなリスクは、主に機能が公開されている場合や、外部のユーザーやその他のソースからの入力を処理する場合に発生することを強調することが重要とされています。

SSRF攻撃では、攻撃者はサーバー(サーバーレス関数のようなもの)を欺くことで、攻撃者がアクセスすべきでない内部または外部のリソースにHTTPリクエストをさせます。サーバー自身がリクエストを行うので、インターネットに公開されていない内部サービスにアクセスすることが可能です。脆弱なサーバーレス関数では、URLを入力として受け取り、そこからデータの取得が行われます。

GCPでは、SSRFを使用してhxxp://metadata.google[.]internal/にあるIMDSにアクセスし、暫定的なサービス アカウント トークンを抽出することができます。攻撃者はこれらのトークンを活用することで、その機能になりすまし、IAMロールの権限内で不正なアクションを実行します。リモート コード実行の脆弱性を利用することで、攻撃者は関数の環境内で任意のコードを実行できます。

AWS Lambdaの場合、RCE攻撃により、AWS_ACCESS_KEY_IDやAWS_SESSION_TOKENなどの環境変数に格納された一時的な認証情報が暴露される可能性があります。

これらの攻撃ベクトルは、クラウドプラットフォーム自体に内在する欠陥ではなく、むしろSSRFやRCEのような脆弱性を導入する可能性のあるアプリケーション開発者によって書かれた安全でないコードから発生することに注意する必要があります。アプリケーション開発者は、入力検証のようなセキュアなコーディング プラクティスを実装することで、これらのリスクを軽減することができます。

攻撃ベクトルのシミュレーション

以下のシミュレーションは、攻撃者がさまざまなクラウド サービス プロバイダー(CSP)においてサーバレス トークンを抽出し、悪意のある活動に使用する可能性を明らかにしたものです。これらの攻撃は、アプリケーション開発者がデプロイした安全でない関数コードを利用する可能性があります。

シミュレーション1: GCP関数からIMDSへの直接アクセスの獲得

このシミュレーションを実施するために、Function Metadata Serviceにアクセスし、以下のパスから2つの異なる添付サービス アカウントのトークンを抽出する以下の2つのGoogle Cloud Run Functionsをデプロイしました。

• hxxp[://]metadata.google[.]internal/computeMetadata/v1/instance/service-accounts/default/token

最初の例は、デフォルトのサービス アカウントの抽出を示したものです。2つ目の例は、カスタム サービス アカウントの抽出を示したものです。これらの例は、脆弱なSSRFコード アプリケーションがメタデータ サービスにアクセスできるのと同様に、コードがメタデータ サービスに直接アクセスできることを示しています。

例1: GCPデフォルト サービス アカウントの抽出

図1に示すように、関数にアタッチされたサービス アカウントは、デフォルトのサーバーレス サービス アカウントでした。図2は、返されたアクセス トークンが同じサービス アカウントに属していることを示したものです。

例2: GCPカスタムサービス アカウントの抽出

図3は、関数にアタッチしたカスタム サービス アカウントです。図4は、カスタム サービス アカウントに属する返されたアクセス トークンを示すもので、調査では返されたトークンを使って環境内で操作を実行しました。

下の図5は、バケットをリストアップするコマンドの例です。

攻撃者はGCPのバケットの内容をリストアップして読み取ることができれば、認証情報、バックアップ、内部設定などの機密ファイルにアクセスすることが可能となります。これにより、データを盗んだり、システムを侵害したり、環境内で横方向に移動したりすることができます。

攻撃者がGCPのEditor権限を持つサービス アカウント(デフォルトのCompute Engineサービス アカウントなど)のアクセストークンを取得すると、ほとんどのサービスでリソースの変更、削除、作成が可能になります。これには、機密データへのアクセス、悪意のあるワークロードのデプロイ、権限の昇格、サービスの中断などが含まれます。エディター アクセスは、事実上、プロジェクトをほぼ完全にコントロールすることを可能にします。

シミュレーション2: AWS Lambda関数の環境変数に格納されたトークンを取得するためにRCEを使用

このシミュレーションでは、Lambda関数の環境変数にアクセスし、そこからAWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKENを抽出しました。

図6は Lambda関数コードの出力を示したものです。

図7は、前のステップで取得した一時的なAWS認証情報(Lambda環境変数)のセットアップを示したものです。

次に、以下のコマンドを使って、認証されたセッションがアクセスできる全てのS3バケットをリストアップしました。

シミュレーション 3: RCEを使用してAzure Functionのローカル アイデンティティ エンドポイントからトークンを取得

今回のシミュレーションでは、Azure Functionの環境変数にアクセスし、リモートコマンドを実行してIDENTITY_ENDPOINTとIDENTITY_HEADERを抽出しました。次に、ローカルのIDエンドポイントから管理されたIDトークンを抽出し、以下の図8に示すパラメータを提供しました。

• リソース
• api-version
• X-IDENTITY-HEADER

トークン窃取の検出と防止

サーバーレス環境におけるトークン窃取の検出

サーバーレス環境におけるトークンの窃取を特定するためには、効果的な検出メカニズムが不可欠です。これらのメカニズムは、不正な活動にフラグを立てるために、振る舞い異常に焦点を当てています。以下は、主要なクラウドプラットフォームで実施されている主な検出戦略の一部です。

検出は以下の2つの段階より構成されます。

• IDがサーバーレス関数にアタッチされていることを検証
• サーバーレス アイデンティティの異常な振る舞いを特定異常とされる振る舞いには以下が含まれます。
  • クラウド プロバイダーに関連付けられていないASN (Autonomous System Numbers)のアドレスなど、機能が実行されているコンテキストに適合しないソースIPアドレス。
  • 不審なユーザー エージェントでリクエストを行うサーバーレス アイデンティティ

ステップ1: サーバーレス アイデンティティの識別

GCPのサーバーレス関数にアタッチされたサービス アカウントを特定するために、ログのserviceAccountDelegationInfoセクションを分析しました。この情報は、サービス アカウントの委任連鎖に関する重要な洞察を提供するものです。具体的には、サービス アカウントが関数にアタッチされると、デフォルトのサーバーレス サービス アカウントに権限が委譲されます。

• Google Cloud Run Service Agent (service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com)
• gcf-admin-robot.iam.gserviceaccount[.]com (service-PROJECT_NUMBER@gcf-admin-robo.iam.gserviceaccount[.]com)

これらのサービス アカウントは、関数の代わりにタスクを実行します。

例えば、図9のログ エントリでは、関数にアタッチされたカスタム サービス アカウント(sa-test@<project-id>.iam.gserviceaccount[.]com)が、Cloud Run Service Agentに権限を委譲していることが確認できます。

上の図9では、authenticationInfoのprincipalEmailフィールドが、使用するサービス アカウント(sa-test[@]xdr-analytics.iam.gserviceaccount[]com)を指定しています。

serviceAccountDelegationInfoは、ファースト パーティ プリンシパル(この場合はservice-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com)を示し、サービス アカウントがCloud FunctionsやCloud Runのようなサーバーレス環境で動作していることを示します。

サーバーレス アイデンティティを発見する効果的なアプローチは、デフォルトのサーバーレス サービス アカウントに権限を委譲したサービス アカウントをプロファイリングすることにあります。これにより、デフォルト以外のサービス アカウントが関数にアタッチされている場合でも、それらが確実に識別されます。

AWSでは、Lambda関数はAWSサービスへのセキュアなアクセスのためにIAMロールに依存しています。これらのロールは一時的な認証情報を生成するものです。LambdaのIDはロール名で識別可能です。

Azureでは、Azure Function AppsにアタッチされたマネージドIDが認証に使用されています。

ステップ2: サーバーレス アイデンティティの異常な振る舞いを特定する

セキュアなクラウド環境では、サーバーレス関数は通常、APIリクエストへの応答やイベントの処理など、自動化された範囲の広いタスクを実行することを目的としています。これらの機能は本来インタラクティブに使用することはできません。しかし、攻撃者がサーバーレス関数の環境やそのIDにアクセスした場合、それを悪用してコマンドライン インターフェース(CLI)コマンド(gcloud CLIやcurlなど)を実行し、クラウドリソースと直接やり取りする可能性があります。

検出の一つの方法は、APIコールのユーザー エージェントを分析することです。ユーザー エージェントが既知のCLIツール(例: gcloud CLI)や侵入テストのフレーム ワークと一致する場合、CLIは通常サーバーレス アイデンティティによって使用されるべきではないため、疑わしいものとしてフラグが立てられます。これは、環境またはサービス アカウントのトークンがエクスプロイトされる可能性を示唆するものです。

注意点として、ユーザー エージェントの情報はAzureのログに表示されないため、ユーザー エージェントに従ってサーバーレス トークンのリモート使用を識別するこの方法は、Azureでは実行できません。

サーバレスIDトークンのリモート使用を検出するもう1つの方法は、トークンの使用場所を既知のクラウド プロバイダのIPアドレスのASN範囲と関連付けることです。これによりリクエストがCSPと関係のない外部IPアドレスから発信された場合、アラートがトリガーされ、クラウド環境の外部でトークンが不正に使用される可能性が強調されます。

予防戦略

サーバーレス トークンのセキュリティ確保には、エクスプロイト攻撃のリスクを最小化するための事前対策、体制管理、実行時監視のセキュリティ プラクティスを組み合わせる必要があります。まず、サーバーレス関数に必要最小限の権限を持つロールを割り当てることで、最小特権の原則を導入します。これにより、トークンの不正使用による潜在的な影響を軽減することができます。

さらに、GCPとAzureのサーバーレス実行環境を保護するために、ネットワーク レベルの制御を設定し、リクエスト検証メカニズムを適用することで、IMDSへのアクセスを制限します。SSRFのようなエクスプロイト攻撃テクニックを使って攻撃者が機密性の高いメタデータやトークン、APIやデータベースのような他のクラウド リソースにアクセスするのを防ぐために、堅牢な入力検証とサニタイズを確実に行います。

結論

サーバーレス コンピューティングは、スケーラビリティ、コスト効率、インフラ管理の簡素化において大きな利点を提供するため、最新のアプリケーション開発に適した選択肢となっています。

これらの機能がクラウド サービスとやり取りできるようにする認証情報は、重要なセキュリティ要素であり、攻撃者の格好の標的です。これらの認証情報が侵害されると、クラウド リソースへの不正アクセスやデータの流出など、深刻な事態につながる可能性があります。

プロアクティブな体制管理とランタイム監視による保護を実装することは、クラウド環境を保護する上で極めて重要な戦略とされています。

組織は、以下を実践することでサーバーレス環境をより適切に保護することができます。

• AWS、Azure、GCPにおけるサーバーレス 認証情報の仕組み、プロビジョニングと管理のベストプラクティスを理解する
• IMDSのエクスプロイトや環境変数へのアクセスによるトークンの流出など、一般的な攻撃ベクトルを認識する

パロアルトネットワークスの保護と緩和策

パロアルトネットワークスのお客様は、以下の製品を通じて、上記の脅威に対する確実な保護を構築いただけます。

情報漏えいの可能性がある場合、または緊急の案件がある場合は、Unit 42インシデント レスポンス チームまでご連絡ください。

• 北米(フリーダイヤル):866.486.4842 (866.4.UNIT42)
• ヨーロッパ/中東/アフリカ(EMEA): +31.20.299.3130
• アジア太平洋: +65.6983.8730
• 日本: +81.50.1790.0200

パロアルトネットワークスは、本調査結果をサイバー脅威アライアンス(CTA)のメンバーと共有しています。CTAの会員は、この情報を利用して、その顧客に対して迅速に保護を提供し、悪意のあるサイバー アクターを組織的に妨害しています。サイバー脅威アライアンスについて詳細を見る。

その他の資料

• Lambda環境変数の操作 - AWS Lambda開発ガイド
• Lambda環境変数の保護- AWS Lambda開発ガイド
• AWS Lambdaで権限を管理する- AWS Lambda開発ガイド
• 関数アイデンティティ - Google Cloud
• AzureリソースのマネージドIDとは何ですか？- Microsoft Learn
• Azure Functionsの保護 - Microsoft Learn
• AWS Secrets Managerとは？- AWS Secret Managerユーザーガイド
• Azure Key Vaultの基本コンセプト - Microsoft Learn
• Secret Managerの概要- Google Cloud Secret Managerドキュメント
• アイデンティティとアクセス管理(IAM)とは？ - Microsoft Security
• AzureリソースのマネージドIDとは何ですか？- Microsoft Learn
• アイデンティティとアクセス制御- AWSセキュリティ入門AWSホワイトペーパー
• サービス アカウントの認証情報- Google Cloud IAMドキュメント
• IAMにおける一時的なセキュリティ認証情報- AWS Identity and Access Managementユーザーガイド
• AWS Security Token Service APIリファレンス- AWS Security Token Serviceドキュメント
• Compute Engineインスタンス- Google Cloudドキュメント
• Google Cloudプロジェクト- Google Cloudドキュメント
• ユーザー管理サービス アカウント- Google Cloudドキュメント
• Cloud Run関数の比較- Google Cloud Runドキュメント
• デフォルトのサービス アカウント- Google Cloudドキュメント
• REST エンドポイントの参照- App ServiceとAzure Functionsのマネージド アイデンティティ
• Azure App Service の環境変数とアプリの設定 - Microsoft Learn
• Azure VM上でAzureリソースのマネージドIDを使用してアクセストークンを取得する方法- Microsoft Learn
• Microsoft Entra IDとは何ですか？- Microsoft Learn
• Azure Key Vaultについて - Microsoft Learn
• Microsoft Entra ID を使用してblobへのアクセスを許可する - Microsoft Learn
• ストレージアカウントの概要 - Microsoft Learn
• Azureロールベースアクセスコントロール(Azure RBAC)とは何ですか？ - Microsoft Learn
• リソース固有のアクセス ポリシー - Microsoft Learn