GCP - IAM Privesc

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

IAM

Znajdź więcej informacji na temat IAM w:

pageGCP - IAM, Principals & Org Policies Enum

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

Atakujący posiadający wymienione uprawnienia będzie mógł zaktualizować przypisaną do Ciebie rolę 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, wykorzystania i czyszczenia środowiska podatnego tutaj, a skrypt w języku Python do wykorzystania tej uprzywilejowanej pozycji tutaj. Aby uzyskać więcej informacji, sprawdź oryginalne badania.

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

Atakujący posiadający wymienione uprawnienia będzie w stanie żądać token dostępu należący do konta usługi, dzięki czemu możliwe jest żądanie tokenu dostępu konta usługi o większych uprawnieniach niż nasze.

Możesz znaleźć skrypt do automatyzacji tworzenia, wykorzystania i czyszczenia środowiska podatnego tutaj oraz skrypt w języku Python do wykorzystania tej uprzywilejowanej pozycji tutaj. Aby uzyskać więcej informacji, sprawdź oryginalne badania.

iam.serviceAccountKeys.create

Atakujący posiadający wymienione uprawnienia będzie w stanie utworzyć zarządzany przez użytkownika klucz dla konta usługi, co umożliwi nam dostęp do GCP jako tego konta 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 środowiska podatnego na atak tutaj oraz skrypt w języku Python do wykorzystania tej uprzywilejowanej pozycji tutaj. Aby uzyskać więcej informacji, sprawdź oryginalne badania.

Należy zauważyć, że iam.serviceAccountKeys.update nie zadziała do modyfikacji klucza konta usługi, ponieważ do tego potrzebne są również uprawnienia iam.serviceAccountKeys.create.

iam.serviceAccounts.implicitDelegation

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

Możesz znaleźć skrypt do automatyzacji tworzenia, wykorzystania i czyszczenia środowiska podatnego na atak tutaj oraz skrypt w języku Python do wykorzystania tej uprzywilejowanej pozycji tutaj. Aby uzyskać więcej informacji, sprawdź oryginalne badania.

Należy zauważyć, że zgodnie z dokumentacją, delegacja działa tylko w celu wygenerowania tokenu za pomocą metody generateAccessToken().

iam.serviceAccounts.signBlob

Atakujący posiadający wymienione uprawnienia będzie w stanie podpisać dowolne dane w GCP. Dlatego będzie możliwe utworzenie niepodpisanego JWT konta usługi, a następnie wysłanie go jako bloba, aby uzyskać podpisane JWT przez nasze docelowe konto usługi. Aby uzyskać więcej informacji, przeczytaj to.

Możesz znaleźć skrypt do automatyzacji tworzenia, wykorzystania i czyszczenia środowiska podatnego na atak tutaj oraz skrypt w języku Python do wykorzystania tej uprzywilejowanej pozycji tutaj i tutaj. Aby uzyskać więcej informacji, sprawdź oryginalne badania.

iam.serviceAccounts.signJwt

Atakujący posiadający wymienione uprawnienia będzie w stanie podpisać poprawnie sformowane tokeny JSON (JWT). Różnica w porównaniu do poprzedniej metody polega na tym, że zamiast sprawić, aby Google podpisał blob zawierający JWT, używamy metody signJWT, która już oczekuje JWT. Ułatwia to korzystanie, ale można podpisywać tylko JWT, a nie dowolne bajty.

Możesz znaleźć skrypt do automatyzacji tworzenia, wykorzystania i czyszczenia środowiska podatnego na atak tutaj oraz skrypt w języku Python do wykorzystania tej uprzywilejowanej pozycji tutaj. Aby uzyskać więcej informacji, sprawdź oryginalne badania.

iam.serviceAccounts.setIamPolicy

Atakujący posiadający wymienione uprawnienia będzie w stanie dodawać polityki IAM do kont usług. Można to wykorzystać, aby przyznać sobie potrzebne uprawnienia do podszywania się pod konto usługi. W poniższym przykładzie przyznajemy sobie rolę roles/iam.serviceAccountTokenCreator dla interesującego nas konta usługi.

gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountTokenCreator"

Skrypt do automatyzacji tworzenia, wykorzystania i czyszczenia środowiska podatnego na atak** znajdziesz tutaj**.

iam.serviceAccounts.actAs

Uprawnienie iam.serviceAccounts.actAs jest podobne do uprawnienia iam:PassRole z AWS. Jest niezbędne do wykonywania zadań, takich jak uruchamianie instancji Compute Engine, ponieważ umożliwia "działanie jako" Konto Usługi, zapewniając bezpieczne zarządzanie uprawnieniami. Bez tego użytkownicy mogą uzyskać nieuprawniony dostęp. Dodatkowo, wykorzystanie iam.serviceAccounts.actAs wymaga różnych metod, z których każda wymaga zestawu uprawnień, w przeciwieństwie do innych metod, które wymagają 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 których można podrobić inne konto usługi:

  • Uwierzytelnianie za pomocą prywatnych kluczy RSA (opisane powyżej)

  • Autoryzacja za pomocą zasad Cloud IAM (opisane tutaj)

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

iam.serviceAccounts.getOpenIdToken

Atakujący posiadający wymienione uprawnienia będzie w stanie wygenerować token OpenID JWT. Są one używane do potwierdzania tożsamości i niekoniecznie posiadają żadne domyślne uprawnienia wobec zasobu.

Zgodnie z tym ciekawym 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ć token OpenID (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 go po prostu 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 obsługujące uwierzytelnianie za pomocą tego rodzaju tokenów to:

Przykład tworzenia tokenu OpenID w imieniu konta usługi można znaleźć tutaj.

Referencje

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Last updated