GCP - IAM Privesc
IAM
Znajdź więcej informacji o IAM w:
GCP - IAM, Principals & Org Policies Enumiam.roles.update
(iam.roles.get
)
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:
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
)
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.
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
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.
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
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ć.
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Frhinosecuritylabs.com%2Fwp-content%2Fuploads%2F2020%2F04%2Fimage2-500x493.png&width=768&dpr=4&quality=100&sign=eb0da8c5&sv=1)
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:
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
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
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
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:
Możesz znaleźć skrypt do automatyzacji tworzenia, eksploatacji i czyszczenia podatnego środowiska tutaj.
iam.serviceAccounts.actAs
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
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ą:
Niektóre usługi, które obsługują uwierzytelnianie za pomocą tego rodzaju tokenów to:
Google Cloud Endpoints (jeśli używasz Google OIDC)
Przykład, jak utworzyć token OpenID w imieniu konta usługi, można znaleźć tutaj.
Referencje
Last updated