Japanese - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

GCP - IAM Privesc

Support HackTricks

IAM

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

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

前述の権限を持つ攻撃者は、あなたに割り当てられたロールを更新し、次のような他のリソースへの追加権限を与えることができます:

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

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.getAccessToken (iam.serviceAccounts.get)

An attacker with the mentioned permissions will be able to サービスアカウントに属するアクセストークンを要求することができる、したがって、私たちの権限よりも多くの権限を持つサービスアカウントのアクセストークンを要求することが可能です。

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

あなたは、脆弱な環境の作成、悪用、クリーンアップを自動化するスクリプトをここで見つけることができます およびこの特権を悪用するための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.implicitDelegationの権限を持つサービスアカウントが、別のサービスアカウントに対してiam.serviceAccounts.getAccessTokenの権限を持っている場合、その第三のサービスアカウントのためにトークンを作成するためにimplicitDelegationを使用することができます。説明を助けるための図は以下の通りです。

ドキュメントによると、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"]
}'

You can find a script to automate the 作成、悪用、脆弱な環境のクリーンアップはこちら and a python script to abuse this privilege こちら. For more information check the 元の研究.

iam.serviceAccounts.signBlob

An attacker with the mentioned permissions will be able to GCPで任意のペイロードに署名する. So it'll be possible to SAの署名されていないJWTを作成し、それをblobとして送信してターゲットのSAによってJWTに署名させる. For more information こちらを読む.

You can find a script to automate the 作成、悪用、脆弱な環境のクリーンアップはこちら and a python script to abuse this privilege こちら and こちら. For more information check the 元の研究.

iam.serviceAccounts.signJwt

An attacker with the mentioned permissions will be able to 適切に形成されたJSONウェブトークン（JWT）に署名する. The difference with the previous method is that JWTを含むblobに署名するためにgoogleに署名させるのではなく、すでにJWTを期待しているsignJWTメソッドを使用します. This makes it easier to use but you can only sign JWT instead of any bytes.

You can find a script to automate the 作成、悪用、脆弱な環境のクリーンアップはこちら and a python script to abuse this privilege こちら. For more information check the 元の研究.

iam.serviceAccounts.setIamPolicy

An attacker with the mentioned permissions will be able to サービスアカウントにIAMポリシーを追加する. You can abuse it to 自分に必要な権限を付与してサービスアカウントを偽装する. In the following example we are granting ourselves the roles/iam.serviceAccountTokenCreator role over the interesting SA:

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

The iam.serviceAccounts.actAs permission is like the iam:PassRole permission from AWS. It's essential for executing tasks, like initiating a Compute Engine instance, as it grants the ability to "actAs" a Service Account, ensuring secure permission management. Without this, users might gain undue access. Additionally, exploiting the iam.serviceAccounts.actAs involves various methods, each requiring a set of permissions, contrasting with other methods that need just one.

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

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

  • RSA秘密鍵を使用した認証（上記で説明）

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

  • GCPサービスでのジョブのデプロイ（ユーザーアカウントの侵害により適用される）

iam.serviceAccounts.getOpenIdToken

An attacker with the mentioned permissions will be able to generate an OpenID JWT. These are used to assert identity and do not necessarily carry any implicit authorization against a resource.

According to this interesting post, it's necessary to indicate the audience (service where you want to use the token to authenticate to) and you will receive a JWT signed by google indicating the service account and the audience of the JWT.

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

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

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

参考文献

HackTricksをサポートする
PreviousGCP - Deploymentmaneger PrivescNextGCP - KMS Privesc

Last updated