GCP <--> Workspace Pivoting
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)
Delegacja w całej domenie Google Workspace pozwala obiektowi tożsamości, czy to zewnętrznej aplikacji z Google Workspace Marketplace, czy wewnętrznego Konta Usługi GCP, na dostęp do danych w całym Workspace w imieniu użytkowników.
To zasadniczo oznacza, że konta usług w projektach GCP organizacji mogą być w stanie udawać użytkowników Workspace tej samej organizacji (lub nawet z innej).
Aby uzyskać więcej informacji na temat tego, jak to dokładnie działa, sprawdź:
Jeśli atakujący skompromitował jakiś dostęp do GCP i zna ważny adres e-mail użytkownika Workspace (najlepiej super admina) firmy, mógłby wyliczyć wszystkie projekty, do których ma dostęp, wyliczyć wszystkie SA projektów, sprawdzić, do których konta usług ma dostęp, i powtórzyć wszystkie te kroki z każdym SA, które może udawać. Mając listę wszystkich kont usług, do których ma dostęp, oraz listę e-maili Workspace, atakujący mógłby spróbować udawać użytkownika z każdym kontem usługi.
Zauważ, że podczas konfigurowania delegacji w całej domenie nie jest potrzebny żaden użytkownik Workspace, dlatego wystarczy znać jednego ważnego, aby było to możliwe. Jednak przywileje udawanego użytkownika będą używane, więc jeśli to Super Admin, będziesz mógł uzyskać dostęp do wszystkiego. Jeśli nie ma żadnego dostępu, to będzie bezużyteczne.
Ten prosty skrypt wygeneruje token OAuth jako delegowany użytkownik, który możesz następnie użyć do uzyskania dostępu do innych interfejsów API Google z lub bez gcloud:
To jest narzędzie, które może przeprowadzić atak, wykonując następujące kroki:
Enumeracja projektów GCP za pomocą API Resource Manager.
Iteracja po każdym zasobie projektu i enumeracja zasobów konta usługi GCP, do których ma dostęp początkowy użytkownik IAM, używając GetIAMPolicy.
Iteracja po każdej roli konta usługi i znalezienie wbudowanych, podstawowych i niestandardowych ról z uprawnieniem serviceAccountKeys.create na docelowym zasobie konta usługi. Należy zauważyć, że rola Edytora z natury posiada to uprawnienie.
Utworzenie nowego klucza prywatnego KEY_ALG_RSA_2048 dla każdego zasobu konta usługi, które zostało znalezione z odpowiednim uprawnieniem w polityce IAM.
Iteracja po każdym nowym koncie usługi i utworzenie obiektu JWT dla niego, który składa się z poświadczeń klucza prywatnego SA i zakresu OAuth. Proces tworzenia nowego obiektu JWT będzie iterować po wszystkich istniejących kombinacjach zakresów OAuth z listy oauth_scopes.txt, aby znaleźć wszystkie możliwości delegacji. Lista oauth_scopes.txt jest aktualizowana o wszystkie zakresy OAuth, które uznaliśmy za istotne do nadużywania tożsamości Workspace.
Metoda _make_authorization_grant_assertion ujawnia konieczność zadeklarowania docelowego użytkownika workspace, określanego jako subject, do generowania JWT pod DWD. Chociaż może się wydawać, że wymaga to konkretnego użytkownika, ważne jest, aby zrozumieć, że DWD wpływa na każdą tożsamość w domenie. W związku z tym, tworzenie JWT dla dowolnego użytkownika domeny wpływa na wszystkie tożsamości w tej domenie, zgodnie z naszą kontrolą enumeracji kombinacji. Mówiąc prosto, jeden ważny użytkownik Workspace jest wystarczający, aby przejść dalej.
Ten użytkownik może być zdefiniowany w pliku config.yaml DeleFriend. Jeśli docelowy użytkownik workspace nie jest jeszcze znany, narzędzie ułatwia automatyczne identyfikowanie ważnych użytkowników workspace poprzez skanowanie użytkowników domeny z rolami w projektach GCP. Kluczowe jest (jeszcze raz) zauważyć, że JWT są specyficzne dla domeny i nie są generowane dla każdego użytkownika; dlatego automatyczny proces celuje w jedną unikalną tożsamość na domenę.
Enumeracja i utworzenie nowego tokena dostępu typu bearer dla każdego JWT i walidacja tokena za pomocą API tokeninfo.
Gitlab stworzył ten skrypt Pythona, który może zrobić dwie rzeczy - wylistować katalog użytkowników i utworzyć nowe konto administracyjne, wskazując json z poświadczeniami SA i użytkownikiem do naśladowania. Oto jak można go użyć:
Możliwe jest sprawdzenie delegacji w całej domenie w https://admin.google.com/u/1/ac/owl/domainwidedelegation.
Napastnik, który ma możliwość tworzenia kont serwisowych w projekcie GCP oraz uprawnienia super administratora do GWS, może utworzyć nową delegację, która pozwala SAs na podszywanie się pod niektórych użytkowników GWS:
Generowanie nowego konta serwisowego i odpowiadającej pary kluczy: W GCP nowe zasoby kont serwisowych mogą być tworzone interaktywnie za pośrednictwem konsoli lub programowo za pomocą bezpośrednich wywołań API i narzędzi CLI. Wymaga to roli iam.serviceAccountAdmin lub dowolnej niestandardowej roli wyposażonej w uprawnienie iam.serviceAccounts.create. Po utworzeniu konta serwisowego przystąpimy do wygenerowania odpowiedniej pary kluczy (uprawnienie iam.serviceAccountKeys.create).
Utworzenie nowej delegacji: Ważne jest, aby zrozumieć, że tylko rola Super Admin ma możliwość skonfigurowania globalnej delegacji w całej domenie w Google Workspace i delegacja w całej domenie nie może być skonfigurowana programowo, może być tworzona i dostosowywana ręcznie za pośrednictwem konsoli Google Workspace.
Utworzenie reguły można znaleźć na stronie Kontrola API → Zarządzaj delegacją w całej domenie w konsoli administracyjnej Google Workspace.
Przypisanie uprawnień zakresów OAuth: Podczas konfigurowania nowej delegacji Google wymaga tylko 2 parametrów, identyfikatora klienta, który jest identyfikatorem OAuth zasobu konta serwisowego GCP, oraz zakresów OAuth, które definiują, jakie wywołania API są wymagane przez delegację.
Pełna lista zakresów OAuth jest dostępna tutaj, ale oto rekomendacja: https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid
Działanie w imieniu docelowej tożsamości: Na tym etapie mamy działający obiekt delegacji w GWS. Teraz, używając prywatnego klucza konta serwisowego GCP, możemy wykonywać wywołania API (w zakresie zdefiniowanym w parametrze zakresu OAuth), aby go uruchomić i działać w imieniu dowolnej tożsamości, która istnieje w Google Workspace. Jak się dowiedzieliśmy, konto serwisowe wygeneruje tokeny dostępu zgodnie z jego potrzebami i zgodnie z uprawnieniami, które ma do aplikacji REST API.
Sprawdź poprzednią sekcję w celu uzyskania narzędzi do wykorzystania tej delegacji.
Identyfikator SA OAuth jest globalny i może być używany do delegacji międzyorganizacyjnej. Nie wprowadzono żadnych ograniczeń, aby zapobiec delegacji międzyglobalnej. Mówiąc prosto, kontakty serwisowe z różnych organizacji GCP mogą być używane do konfigurowania delegacji w całej domenie w innych organizacjach Workspace. Skutkuje to potrzebą tylko dostępu Super Admin do Workspace, a nie dostępu do tego samego konta GCP, ponieważ przeciwnik może tworzyć konta serwisowe i prywatne klucze na swoim osobiście kontrolowanym koncie GCP.
Zgodnie z domyślnymi ustawieniami użytkownicy Workspace mają uprawnienia do tworzenia nowych projektów, a gdy nowy projekt jest tworzony, twórca otrzymuje rolę właściciela.
Dlatego użytkownik może utworzyć projekt, włączyć API do enumeracji Workspace w swoim nowym projekcie i spróbować go enumerować.
Aby użytkownik mógł enumerować Workspace, musi również mieć wystarczające uprawnienia Workspace (nie każdy użytkownik będzie mógł enumerować katalog).
Sprawdź więcej enumeracji w:
Możesz znaleźć więcej informacji na temat przepływu gcloud do logowania w:
Jak tam wyjaśniono, gcloud może żądać zakresu https://www.googleapis.com/auth/drive, co pozwoliłoby użytkownikowi uzyskać dostęp do dysku użytkownika.
Jako atakujący, jeśli fizycznie skompromitowałeś komputer użytkownika i użytkownik jest nadal zalogowany na swoje konto, możesz się zalogować, generując token z dostępem do dysku, używając:
If an attacker compromises the computer of a user he could also modify the file google-cloud-sdk/lib/googlecloudsdk/core/config.py and add in the CLOUDSDK_SCOPES the scope 'https://www.googleapis.com/auth/drive':
Dlatego następnym razem, gdy użytkownik się zaloguje, utworzy token z dostępem do dysku, który atakujący mógłby wykorzystać do uzyskania dostępu do dysku. Oczywiście przeglądarka wskaże, że wygenerowany token będzie miał dostęp do dysku, ale ponieważ użytkownik sam wywoła gcloud auth login, prawdopodobnie nie będzie niczego podejrzewał.
Aby wylistować pliki na dysku: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"
If an attacker has complete access over GWS he will be able to access groups with privilege access over GCP or even users, therefore moving from GWS to GCP is usually more "simple" just because użytkownicy w GWS mają wysokie uprawnienia w GCP.
By default users can swobodnie dołączać do grup Workspace w Organizacji i te grupy mogą mieć przypisane uprawnienia GCP (sprawdź swoje grupy w https://groups.google.com/).
Abusing the google groups privesc you might be able to escalate to a group with some kind of privileged access to GCP.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
