GCP - IAM Privesc

htARTE(HackTricks AWS Red Team Expert) でゼロからヒーローまでAWSハッキングを学ぶ

HackTricks をサポートする他の方法:

IAM

IAM に関する詳細情報は以下で確認できます:

pageGCP - IAM, Principals & Org Policies Enum

iam.roles.update (iam.roles.get)

上記の権限を持つ攻撃者は、あなたに割り当てられたロールを更新し、他のリソースに追加の権限を付与することができます。

gcloud iam roles update <rol name> --project <project> --add-permissions <permission>

以下は、特権エスカレーションの環境を自動化するスクリプトと、この特権を悪用するためのPythonスクリプトがあります。詳細については、元の研究をご覧ください。

iam.serviceAccounts.getAccessToken (iam.serviceAccounts.get)

上記の権限を持つ攻撃者は、サービスアカウントに属するアクセストークンをリクエストすることができます。そのため、自分よりも権限の高いサービスアカウントのアクセストークンをリクエストすることが可能です。

こちらに特権エスカレーションの環境を自動化するスクリプトがあり、この特権を悪用するためのPythonスクリプトはこちらです。詳細については、元の研究をご覧ください。

iam.serviceAccountKeys.create

上記の権限を持つ攻撃者は、サービスアカウント用のユーザー管理キーを作成することができます。これにより、そのサービスアカウントとしてGCPにアクセスすることが可能となります。

gcloud iam service-accounts keys create --iam-account <name> /tmp/key.json

gcloud auth activate-service-account --key-file=sa_cred.json

こちらに脆弱性環境の作成、悪用、クリーニングを自動化するスクリプトがあります。また、この特権を悪用するためのPythonスクリプトはこちらにあります。詳細については、オリジナルの研究を参照してください。

iam.serviceAccountKeys.updateはSAのキーを変更するためにはiam.serviceAccountKeys.create権限も必要です。

iam.serviceAccounts.implicitDelegation

サードパーティのサービスアカウントに対して**iam.serviceAccounts.getAccessToken権限を持つサービスアカウントでiam.serviceAccounts.implicitDelegation権限を持っている場合、implicitDelegationを使用してそのサードパーティのサービスアカウントのためのトークンを作成**できます。説明を助けるための図は以下の通りです。

こちらに脆弱性環境の作成、悪用、クリーニングを自動化するスクリプトがあります。また、この特権を悪用するためのPythonスクリプトはこちらにあります。詳細については、オリジナルの研究を参照してください。

ドキュメントによると、委任はgenerateAccessToken()メソッドを使用してトークンを生成するためにのみ機能します。

iam.serviceAccounts.signBlob

上記の権限を持つ攻撃者は、GCP内で任意のペイロードに署名できます。そのため、対象となるSAの未署名JWTを作成し、それをブロブとして送信してSAに署名させることが可能です。詳細についてはこちらを参照してください。

こちらに脆弱性環境の作成、悪用、クリーニングを自動化するスクリプトがあります。また、この特権を悪用するためのPythonスクリプトはこちらおよびこちらにあります。詳細については、オリジナルの研究を参照してください。

iam.serviceAccounts.signJwt

上記の権限を持つ攻撃者は、正しく形成されたJSON Web Token(JWT)に署名できます。前の方法との違いは、GoogleにJWTを含むブロブに署名させるのではなく、すでにJWTを期待するsignJWTメソッドを使用することです。これにより使用は簡単になりますが、JWTの署名のみが可能であり、任意のバイトを署名することはできません。

こちらに脆弱性環境の作成、悪用、クリーニングを自動化するスクリプトがあります。また、この特権を悪用するためのPythonスクリプトはこちらにあります。詳細については、オリジナルの研究を参照してください。

iam.serviceAccounts.setIamPolicy

上記の権限を持つ攻撃者は、サービスアカウントにIAMポリシーを追加できます。これを悪用して、サービスアカウントを偽装するために必要な権限を自分に付与することができます。以下の例では、興味深いSAにroles/iam.serviceAccountTokenCreatorロールを付与しています。

gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountTokenCreator"

iam.serviceAccounts.actAs

iam.serviceAccounts.actAs権限は、AWSのiam:PassRole権限のようなものです。Compute Engineインスタンスの起動などのタスクを実行するために不可欠であり、Service Accountを「actAs」する権限を付与することで、安全な権限管理が確保されます。これがないと、ユーザーが不当なアクセス権を取得する可能性があります。また、iam.serviceAccounts.actAsを悪用するには、各種の権限セットが必要な異なる方法があり、他の方法とは異なります。

サービスアカウントの偽装

サービスアカウントを偽装することは、新しいかつより良い権限を取得するのに非常に役立ちます。別のサービスアカウントを偽装する方法には、次の3つの方法があります:

  • RSAプライベートキーを使用した認証(上で説明済み)

  • Cloud IAMポリシーを使用した認可(ここで説明)

  • GCPサービス上でジョブを展開する(ユーザーアカウントの侵害によりより適用される)

iam.serviceAccounts.getOpenIdToken

上記の権限を持つ攻撃者は、OpenID JWTを生成することができます。これらはアイデンティティを主張するために使用され、リソースに対する暗黙の認可を必ずしも持っているわけではありません。

この興味深い投稿によると、JWTの受信者(トークンを使用して認証するサービス)を示す必要があり、Googleによって署名されたJWTがサービスアカウントとJWTの受信者を示します。

アクセス権を持っている場合、次のようにOpenIDTokenを生成できます:

# First activate the SA with iam.serviceAccounts.getOpenIdToken over the other SA
gcloud auth activate-service-account --key-file=/path/to/svc_account.json
# Then, generate token
gcloud auth print-identity-token "${ATTACK_SA}@${PROJECT_ID}.iam.gserviceaccount.com" --audiences=https://example.com

その後、それを使用してサービスにアクセスできます:

curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app

いくつかのサービスは、この種のトークンを使用した認証をサポートしています:

サービスアカウントを代表してOpenIDトークンを作成する例はこちらにあります。

参考文献

htARTE(HackTricks AWS Red Team Expert)でAWSハッキングをゼロからヒーローまで学ぶ こちら

HackTricksをサポートする他の方法:

最終更新