GCP - IAM Privesc
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Znajdź więcej informacji o IAM w:
GCP - IAM, Principals & Org Policies Enumiam.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:
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.
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.
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.
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 w celu wygenerowania tokena za pomocą metody generateAccessToken(). Oto jak uzyskać token, używając API bezpośrednio:
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ć podpis JWT od 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ć, że Google podpisuje 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 potrzebne do podszywania się pod konto serwisowe. W poniższym przykładzie przyznajemy sobie rolę roles/iam.serviceAccountTokenCreator
nad interesującym SA:
Możesz znaleźć skrypt do automatyzacji tworzenia, wykorzystywania 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 "działanie jako" konto usługi, zapewniając bezpieczne zarządzanie uprawnieniami. Bez tego użytkownicy mogą uzyskać nieuzasadniony 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.
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ą:
Możesz go następnie użyć do uzyskania dostępu do usługi za pomocą:
Niektóre usługi, które wspierają uwierzytelnianie za pomocą tego rodzaju tokenów to:
Google Cloud Endpoints (jeśli używasz Google OIDC)
Możesz znaleźć przykład, jak stworzyć token OpenID w imieniu konta usługi tutaj.
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)