GCP - IAM Privesc

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

IAM

IAMに関する詳細情報は以下を参照してください:

GCP - 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`)

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

gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
auth print-access-token

自動化スクリプトはこちらで見つけることができ、この権限を悪用するためのpythonスクリプトはこちらで見つけることができます。詳細についてはオリジナルの研究を確認してください。

`iam.serviceAccountKeys.create`

上記の権限を持つ攻撃者は、Service Accountのユーザー管理キーを作成することができ、これによりそのService Accountとして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`

もし、あるService Accountに対して**iam.serviceAccounts.implicitDelegationの権限を持っていて、そのService Accountが第三のService Accountに対してiam.serviceAccounts.getAccessTokenの権限を持っている場合、implicitDelegationを使用してその第三のService Accountのトークンを作成する**ことができます。以下の図はその説明を助けるためのものです。

ドキュメントによると、gcloudの委任はgenerateAccessToken()メソッドを使用してトークンを生成する場合にのみ機能することに注意してください。ここではAPIを直接使用してトークンを取得する方法を示します:

curl -X POST \
'https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/'"${TARGET_SERVICE_ACCOUNT}"':generateAccessToken' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer '"$(gcloud auth print-access-token)" \
-d '{
"delegates": ["projects/-/serviceAccounts/'"${DELEGATED_SERVICE_ACCOUNT}"'"],
"scope": ["https://www.googleapis.com/auth/cloud-platform"]
}'

自動化スクリプトはこちらで見つけることができ、この権限を悪用するためのPythonスクリプトはこちらで見つけることができます。詳細についてはオリジナルの研究を参照してください。

`iam.serviceAccounts.signBlob`

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

自動化スクリプトはこちらで見つけることができ、この権限を悪用するためのPythonスクリプトはこちらおよびこちらで見つけることができます。詳細についてはオリジナルの研究を参照してください。

`iam.serviceAccounts.signJwt`

上記の権限を持つ攻撃者は、正しく形成されたJSON Webトークン（JWT）に署名することができます。前の方法との違いは、JWTを含むblobに署名させる代わりに、すでにJWTを期待しているsignJWTメソッドを使用することです。これにより使用が簡単になりますが、任意のバイトではなくJWTにのみ署名できます。

`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"

# If you still have prblem grant yourself also this permission
gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \ \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountUser"

自動化スクリプトはこちらで見つけることができます。

`iam.serviceAccounts.actAs`

iam.serviceAccounts.actAs permissionはAWSのiam:PassRole permissionに似ています。これは、Compute Engineインスタンスの起動などのタスクを実行するために不可欠であり、Service Accountとして「actAs」する能力を付与し、安全な権限管理を確保します。これがないと、ユーザーが不適切なアクセスを得る可能性があります。さらに、iam.serviceAccounts.actAsの悪用にはさまざまな方法があり、それぞれに一連の権限が必要であり、他の方法とは対照的に1つの権限だけでは済みません。

Service account impersonation

Service accountを偽装することは、新しいより良い権限を取得するために非常に有用です。以下の3つの方法で他のService accountを偽装することができます：

RSA private keysを使用した認証（上記でカバー）
Cloud IAM policiesを使用した認可（ここでカバー）
GCPサービスにジョブをデプロイ（ユーザーアカウントの侵害により適用）

`iam.serviceAccounts.getOpenIdToken`

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

この興味深い投稿によると、オーディエンス（トークンを使用して認証したいサービス）を指定する必要があり、Googleによって署名されたJWTが返され、そのJWTのService accountとオーディエンスが示されます。

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

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

Google Cloud Run
Google Cloud Functions
Google Identity Aware Proxy
Google Cloud Endpoints (Google OIDCを使用している場合)

サービスアカウントの代わりにOpenIDトークンを作成する方法の例はこちらで見つけることができます。

参考文献

https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/

AWS Hackingを学び、練習する:HackTricks Training AWS Red Team Expert (ARTE) GCP Hackingを学び、練習する: HackTricks Training GCP Red Team Expert (GRTE)

HackTricksをサポートする

サブスクリプションプランをチェック！
💬 Discordグループまたはtelegramグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。**
ハッキングトリックを共有するには、 HackTricksおよびHackTricks CloudのgithubリポジトリにPRを提出してください。

PreviousGCP - Deploymentmaneger Privesc NextGCP - KMS Privesc

Last updated 1 month ago

IAM

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

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

iam.serviceAccountKeys.create

iam.serviceAccounts.implicitDelegation

iam.serviceAccounts.signBlob

iam.serviceAccounts.signJwt

iam.serviceAccounts.setIamPolicy

iam.serviceAccounts.actAs