GCP - IAM Privesc
Tip
Ucz się & ćwicz AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Wspieraj HackTricks
- Sprawdź subscription plans!
- Dołącz do 💬 Discord group lub telegram group lub śledź nas na Twitterze 🐦 @hacktricks_live.
- Podziel się hacking tricks, zgłaszając PRy do HackTricks i HackTricks Cloud github repos.
IAM
Więcej informacji o IAM znajdziesz w:
GCP - IAM, Principals & Org Policies Enum
iam.roles.update (iam.roles.get)
Atakujący z wymienionymi uprawnieniami będzie mógł zaktualizować rolę przypisaną tobie i nadać dodatkowe uprawnienia do innych zasobów, takich jak:
gcloud iam roles update <rol name> --project <project> --add-permissions <permission>
Możesz znaleźć skrypt automatyzujący tworzenie, exploit i czyszczenie środowiska vuln tutaj oraz skrypt w pythonie do nadużycia tego uprawnienia here. Więcej informacji znajdziesz w original research.
gcloud iam roles update <Rol_NAME> --project <PROJECT_ID> --add-permissions <Permission>
iam.roles.create & iam.serviceAccounts.setIamPolicy
Uprawnienie iam.roles.create pozwala na tworzenie ról niestandardowych w projekcie/organizacji. W rękach atakującego jest to niebezpieczne, ponieważ umożliwia zdefiniowanie nowych zestawów uprawnień, które mogą później zostać przypisane do podmiotów (na przykład przy użyciu uprawnienia iam.serviceAccounts.setIamPolicy) w celu eskalacji uprawnień.
gcloud iam roles create <ROLE_ID> \
--project=<PROJECT_ID> \
--title="<Title>" \
--description="<Description>" \
--permissions="permission1,permission2,permission3"
iam.serviceAccounts.getAccessToken (iam.serviceAccounts.get)
Atakujący posiadający wymienione uprawnienia będzie mógł request an access token that belongs to a Service Account, więc możliwe jest uzyskanie access tokenu Service Account o większych uprawnieniach niż nasze.
gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
auth print-access-token
Możesz znaleźć skrypt automatyzujący creation, exploit and cleaning of a vuln environment here oraz skrypt w Pythonie do wykorzystania tego uprawnienia here. Aby uzyskać więcej informacji, sprawdź original research.
iam.serviceAccountKeys.create
Atakujący z wymienionymi uprawnieniami będzie w stanie utworzyć klucz zarządzany przez użytkownika dla Service Account, co pozwoli nam uzyskać dostęp do GCP jako ten Service Account.
gcloud iam service-accounts keys create --iam-account <name> /tmp/key.json
gcloud auth activate-service-account --key-file=sa_cred.json
Możesz znaleźć skrypt automatyzujący creation, exploit and cleaning of a vuln environment here oraz skrypt w Pythonie do wykorzystania tego uprawnienia here. Więcej informacji znajdziesz w original research.
Zwróć uwagę, że iam.serviceAccountKeys.update won’t work to modify the key of a SA ponieważ do tego potrzebne jest również uprawnienie iam.serviceAccountKeys.create.
iam.serviceAccounts.implicitDelegation
Jeśli masz uprawnienie iam.serviceAccounts.implicitDelegation na Service Account, który ma uprawnienie iam.serviceAccounts.getAccessToken na trzecim Service Account, możesz użyć implicitDelegation, aby create a token for that third Service Account. Poniżej diagram wyjaśniający.

Zwróć uwagę, że zgodnie z documentation, delegacja gcloud działa tylko do wygenerowania tokena przy użyciu metody generateAccessToken(). Poniżej jak uzyskać token korzystając bezpośrednio z 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"]
}'
Możesz znaleźć skrypt do automatyzacji creation, exploit and cleaning of a vuln environment here oraz skrypt w Pythonie do nadużycia tego przywileju here. Więcej informacji znajdziesz w original research.
iam.serviceAccounts.signBlob
Atakujący z wymienionymi uprawnieniami będzie w stanie podpisać dowolne payloady w GCP. Oznacza to, że będzie możliwe utworzenie niepodpisanego JWT należącego do SA, a następnie wysłanie go jako blob, aby uzyskać podpis JWT przez docelowy SA. Więcej informacji znajdziesz tutaj.
Możesz znaleźć skrypt do automatyzacji creation, exploit and cleaning of a vuln environment here oraz skrypt w Pythonie do nadużycia tego przywileju here i here. Więcej informacji znajdziesz w original research.
iam.serviceAccounts.signJwt
Atakujący z wymienionymi uprawnieniami będzie mógł podpisać prawidłowo sformowane JSON Web Tokeny (JWT). Różnica w stosunku do poprzedniej metody polega na tym, że zamiast sprawiać, by google podpisał blob zawierający JWT, używamy metody signJWT, która od razu oczekuje JWT. Ułatwia to użycie, ale pozwala podpisać tylko JWT, zamiast dowolnych bajtów.
Możesz znaleźć skrypt do automatyzacji creation, exploit and cleaning of a vuln environment here oraz skrypt w Pythonie do nadużycia tego przywileju here. Więcej informacji znajdziesz w original research.
iam.serviceAccounts.setIamPolicy
Atakujący z wymienionymi uprawnieniami będzie mógł dodać polityki IAM do service accounts. Można to wykorzystać, aby przyznać sobie uprawnienia potrzebne do impersonacji service account. W poniższym przykładzie przyznajemy sobie rolę roles/iam.serviceAccountTokenCreator nad interesującym 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"
Możesz znaleźć skrypt automatyzujący creation, exploit and cleaning of a vuln environment here.
iam.serviceAccounts.actAs
Uprawnienie iam.serviceAccounts.actAs jest podobne do uprawnienia iam:PassRole permission from AWS. Jest niezbędne do wykonywania zadań, takich jak uruchomienie instancji Compute Engine, ponieważ daje możliwość „actAs” Service Account, zapewniając bezpieczne zarządzanie uprawnieniami. Bez tego użytkownicy mogą uzyskać nadmierny dostęp. Dodatkowo wykorzystanie iam.serviceAccounts.actAs obejmuje różne metody, z których każda wymaga zestawu uprawnień, w przeciwieństwie do innych metod, które potrzebują tylko jednego.
Service account impersonation
Podszywanie się pod Service Account może być bardzo przydatne do uzyskania nowych i lepszych uprawnień. Istnieją trzy sposoby, w jakie możesz impersonate another service account:
- Uwierzytelnianie using RSA private keys (patrz wyżej)
- Autoryzacja using Cloud IAM policies (omówione tutaj)
- Deploying jobs on GCP services (bardziej dotyczy kompromitacji konta użytkownika)
iam.serviceAccounts.getOpenIdToken
Atakujący posiadający wymienione uprawnienia będzie w stanie wygenerować OpenID JWT. Służą one do potwierdzania tożsamości i niekoniecznie zawierają domyślną autoryzację do zasobu.
Zgodnie z tym interesting post, konieczne jest określenie audience (usługi, w której chcesz użyć tokena do uwierzytelnienia) i otrzymasz JWT podpisany przez google wskazujący service account oraz audience JWT.
Możesz wygenerować OpenIDToken (jeśli masz dostęp) za pomocą:
# 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
Następnie możesz po prostu użyć go, aby uzyskać dostęp do usługi za pomocą:
curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app
Niektóre usługi, które obsługują uwierzytelnianie za pomocą tego typu tokenów to:
- Google Cloud Run
- Google Cloud Functions
- Google Identity Aware Proxy
- Google Cloud Endpoints (jeśli używasz Google OIDC)
Przykład, jak utworzyć token OpenID w imieniu konta serwisowego znajdziesz here.
Referencje
Tip
Ucz się & ćwicz AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Wspieraj HackTricks
- Sprawdź subscription plans!
- Dołącz do 💬 Discord group lub telegram group lub śledź nas na Twitterze 🐦 @hacktricks_live.
- Podziel się hacking tricks, zgłaszając PRy do HackTricks i HackTricks Cloud github repos.
HackTricks Cloud

