GCP - IAM Privesc

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

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 przyznać 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, wykorzystywania i czyszczenia podatnego środowiska tutaj oraz skrypt w Pythonie do nadużywania tego uprawnienia tutaj. Po więcej informacji sprawdź oryginalne badania.

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

Atakujący z wymienionymi uprawnieniami będzie mógł zażądać tokena dostępu, który należy do konta usługi, więc możliwe jest zażądanie tokena 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, wykorzystania i czyszczenia podatnego środowiska tutaj oraz skrypt Pythona do nadużywania tego uprawnienia tutaj. Po więcej informacji sprawdź oryginalne badania.

iam.serviceAccountKeys.create

Atakujący z wymienionymi uprawnieniami będzie mógł 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, wykorzystania i czyszczenia podatnego środowiska tutaj oraz skrypt w Pythonie do nadużywania tego uprawnienia tutaj. Po więcej informacji sprawdź oryginalne badania.

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 do utworzenia tokena 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 w celu wygenerowania tokena za pomocą metody generateAccessToken(). Oto jak uzyskać token, używając API bezpośrednio:

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 Pythona do nadużywania tego uprawnienia tutaj. Po więcej informacji sprawdź oryginalne badania.

iam.serviceAccounts.signBlob

Atakujący z wymienionymi uprawnieniami będzie mógł podpisywać dowolne ładunki w GCP. Będzie więc możliwe utworzenie niesigned JWT SA, a następnie wysłanie go jako blob, aby uzyskać podpisany JWT przez docelowego SA. Po więcej informacji przeczytaj to.

Możesz znaleźć skrypt do automatyzacji tworzenia, eksploatacji i czyszczenia podatnego środowiska tutaj oraz skrypt Pythona do nadużywania tego uprawnienia tutaj i tutaj. Po więcej informacji sprawdź oryginalne badania.

iam.serviceAccounts.signJwt

Atakujący z wymienionymi uprawnieniami będzie mógł podpisywać poprawnie sformułowane tokeny JWT (JSON web tokens). Różnica w porównaniu do poprzedniej metody polega na tym, że zamiast sprawiać, by Google podpisał blob zawierający JWT, używamy metody signJWT, która już oczekuje JWT. Ułatwia to użycie, ale można podpisać tylko JWT, a nie dowolne bajty.

Możesz znaleźć skrypt do automatyzacji tworzenia, eksploatacji i czyszczenia podatnego środowiska tutaj oraz skrypt Pythona do nadużywania tego uprawnienia tutaj. Po więcej informacji sprawdź oryginalne badania.

iam.serviceAccounts.setIamPolicy

Atakujący z wymienionymi uprawnieniami będzie mógł dodawać polityki IAM do kont serwisowych. Możesz to nadużyć, aby przyznać sobie uprawnienia, których potrzebujesz do podszywania się pod konto serwisowe. W następującym 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:[e-mail]" \
--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:[e-mail]" \
--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ż przyznaje możliwość "działania jako" 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żesz podszywać się pod inne konto usługi:

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

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

• Wdrażanie zadań w usługach GCP (bardziej stosowane w przypadku kompromitacji konta użytkownika)

iam.serviceAccounts.getOpenIdToken

Atakujący z wymienionymi uprawnieniami będzie w stanie wygenerować token OpenID JWT. Służą one do potwierdzania tożsamości i niekoniecznie niosą ze sobą jakąkolwiek domyślną autoryzację wobec zasobu.

Zgodnie z tym interesującym postem, konieczne jest wskazanie odbiorcy (usługi, w której chcesz użyć tokena 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

Następnie możesz po prostu użyć tego, 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 wspierają uwierzytelnianie za pomocą tego rodzaju tokenów to:

• Google Cloud Run

• Google Cloud Functions

• Google Identity Aware Proxy

• Google Cloud Endpoints (jeśli używasz Google OIDC)

Możesz znaleźć przykład, jak stworzyć token OpenID w imieniu konta usługi tutaj.

Odniesienia

• https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Wsparcie HackTricks

• Sprawdź plany subskrypcyjne!

• Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @hacktricks_live.

• Dziel się trikami hackingowymi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów na GitHubie.