Polish - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP - IAM Privesc

Wspieraj HackTricks

IAM

Znajdź więcej informacji o IAM 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ą do Ciebie i nadać Ci dodatkowe uprawnienia do innych zasobów, takich jak:

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

Możesz znaleźć skrypt do automatyzacji tworzenia, eksploatacji i czyszczenia podatnego środowiska tutaj oraz skrypt w Pythonie do nadużywania tego przywileju tutaj. Więcej informacji znajdziesz w oryginalnych badaniach.

iam.serviceAccounts.getAccessToken (iam.serviceAccounts.get)

Atakujący z wymienionymi uprawnieniami będzie w stanie zażądać tokenu dostępu należącego do Konta Usługi, więc możliwe jest zażądanie tokenu dostępu Konta Usługi z większymi uprawnieniami niż nasze.

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

Możesz znaleźć skrypt do automatyzacji tworzenia, eksploatacji i czyszczenia podatnego środowiska tutaj oraz skrypt w Pythonie do nadużywania tego uprawnienia tutaj. Więcej informacji znajdziesz w oryginalnych badaniach.

iam.serviceAccountKeys.create

Atakujący z wymienionymi uprawnieniami będzie w stanie utworzyć klucz zarządzany przez użytkownika dla Konta Usługi, co pozwoli nam uzyskać dostęp do GCP jako to Konto Usługi.

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 do automatyzacji tworzenia, eksploatacji i czyszczenia podatnego środowiska tutaj oraz skrypt w Pythonie do nadużywania tego uprawnienia tutaj. Więcej informacji znajdziesz w oryginalnych badaniach.

Zauważ, że iam.serviceAccountKeys.update nie zadziała, aby zmodyfikować klucz SA, ponieważ do tego potrzebne są również uprawnienia iam.serviceAccountKeys.create.

iam.serviceAccounts.implicitDelegation

Jeśli masz uprawnienie iam.serviceAccounts.implicitDelegation na Koncie Usługi, które ma uprawnienie iam.serviceAccounts.getAccessToken na trzecim Koncie Usługi, to możesz użyć implicitDelegation, aby utworzyć token dla tego trzeciego Konta Usługi. Oto diagram, który pomoże to wyjaśnić.

Zauważ, że zgodnie z dokumentacją, delegacja gcloud działa tylko do generowania tokena za pomocą metody generateAccessToken(). Oto jak uzyskać token bezpośrednio za pomocą 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 tworzenia, eksploatacji i czyszczenia podatnego środowiska tutaj oraz skrypt w Pythonie do nadużywania tego przywileju tutaj. Więcej informacji znajdziesz w oryginalnym badaniu.

iam.serviceAccounts.signBlob

Atakujący z wymienionymi uprawnieniami będzie w stanie podpisywać dowolne ładunki w GCP. Będzie więc możliwe utworzenie niepodpisanego JWT SA, a następnie wysłanie go jako blob, aby uzyskać podpis JWT przez SA, który jest naszym celem. Więcej informacji znajdziesz tutaj.

Możesz znaleźć skrypt do automatyzacji tworzenia, eksploatacji i czyszczenia podatnego środowiska tutaj oraz skrypt w Pythonie do nadużywania tego przywileju tutaj i tutaj. Więcej informacji znajdziesz w oryginalnym badaniu.

iam.serviceAccounts.signJwt

Atakujący z wymienionymi uprawnieniami będzie w stanie podpisywać poprawnie sformułowane JSON web tokens (JWTs). Różnica w stosunku do poprzedniej metody polega na tym, że zamiast zmuszać Google do podpisania bloba zawierającego JWT, używamy metody signJWT, która już oczekuje JWT. To ułatwia użycie, ale można podpisać tylko JWT zamiast dowolnych bajtów.

Możesz znaleźć skrypt do automatyzacji tworzenia, eksploatacji i czyszczenia podatnego środowiska tutaj oraz skrypt w Pythonie do nadużywania tego przywileju tutaj. Więcej informacji znajdziesz w oryginalnym badaniu.

iam.serviceAccounts.setIamPolicy

Atakujący z wymienionymi uprawnieniami będzie w stanie dodawać polityki IAM do kont usługowych. Możesz to wykorzystać, aby przyznać sobie uprawnienia potrzebne do podszywania się pod konto usługowe. 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 do automatyzacji tworzenia, eksploatacji i czyszczenia podatnego środowiska tutaj.

iam.serviceAccounts.actAs

Uprawnienie iam.serviceAccounts.actAs jest podobne do uprawnienia iam:PassRole z AWS. Jest kluczowe do wykonywania zadań, takich jak uruchamianie instancji Compute Engine, ponieważ umożliwia "actAs" Konto Usługi, zapewniając bezpieczne zarządzanie uprawnieniami. Bez tego użytkownicy mogą uzyskać nieuzasadniony dostęp. Dodatkowo, eksploatacja 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.

Podszywanie się pod konto usługi

Podszywanie się pod konto usługi może być bardzo przydatne do uzyskania nowych i lepszych uprawnień. Istnieją trzy sposoby, w jakie można podszywać się pod inne konto usługi:

  • Uwierzytelnianie za pomocą prywatnych kluczy RSA (omówione powyżej)

  • Autoryzacja za pomocą polityk Cloud IAM (omówione tutaj)

  • Wdrażanie zadań na usługach GCP (bardziej aplikowalne do kompromitacji konta użytkownika)

iam.serviceAccounts.getOpenIdToken

Atakujący z wymienionymi uprawnieniami będzie w stanie wygenerować OpenID JWT. Są one używane do potwierdzania tożsamości i niekoniecznie niosą ze sobą jakiekolwiek domyślne uprawnienia do zasobu.

Zgodnie z tym interesującym postem, konieczne jest wskazanie odbiorcy (usługi, w której chcesz użyć tokenu do uwierzytelnienia) i otrzymasz JWT podpisany przez Google, wskazujący konto usługi i odbiorcę 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
Then you can just use it to access the service with:

Następnie możesz go użyć, 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 rodzaju tokenów to:

Przykład, jak utworzyć token OpenID w imieniu konta usługi, można znaleźć tutaj.

Referencje

Wspieraj HackTricks
PreviousGCP - Deploymentmaneger PrivescNextGCP - KMS Privesc

Last updated