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 uzyskanie dostępu do danych w Workspace w imieniu użytkowników.
To zasadniczo oznacza, że kontakty usługowe 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ź:
GCP - Understanding Domain-Wide DelegationJeś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 kont usługowych ma dostęp, i powtórzyć wszystkie te kroki z każdym SA, którego może udawać. Mając listę wszystkich kont usługowych, 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ługowym.
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 wymagane do udawania. Jednakże, 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:
Enumerate GCP Projects przy użyciu Resource Manager API.
Iteruj po każdym zasobie projektu i enumerate GCP Service account resources, do których ma dostęp początkowy użytkownik IAM, używając GetIAMPolicy.
Iteruj po każdej roli konta usługi i znajdź wbudowane, podstawowe i niestandardowe role z uprawnieniem serviceAccountKeys.create na docelowym zasobie konta usługi. Należy zauważyć, że rola Edytora z natury posiada to uprawnienie.
Utwórz nowy KEY_ALG_RSA_2048 klucz prywatny dla każdego zasobu konta usługi, które zostało znalezione z odpowiednim uprawnieniem w polityce IAM.
Iteruj po każdym nowym koncie usługi i utwórz obiekt 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 prościej, jeden ważny użytkownik Workspace jest wystarczający, aby kontynuować.
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ę.
Enumerate and create a new bearer access token dla każdego JWT i zweryfikuj token za pomocą tokeninfo API.
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żytkownika do naśladowania. Oto jak można go użyć:
Możliwe jest sprawdzenie delegacji na poziomie domeny 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 na poziomie domeny w Google Workspace i delegacja na poziomie domeny 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 API controls → Manage Domain-Wide delegation in Google Workspace Admin console.
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 na poziomie domeny 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ć enumerować go.
Aby użytkownik mógł enumerować Workspace, musi również mieć wystarczające uprawnienia do Workspace (nie każdy użytkownik będzie mógł enumerować katalog).
Sprawdź więcej enumeracji w:
GCP - IAM, Principals & Org Policies EnumMoż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 przejął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:
Jeśli atakujący przejmie komputer użytkownika, może również zmodyfikować plik google-cloud-sdk/lib/googlecloudsdk/core/config.py i dodać do CLOUDSDK_SCOPES zakres 'https://www.googleapis.com/auth/drive':
Dlatego następnym razem, gdy użytkownik się zaloguje, utworzy token z dostępem do drive, który atakujący może wykorzystać do uzyskania dostępu do drive. Oczywiście przeglądarka wskaże, że wygenerowany token będzie miał dostęp do drive, ale ponieważ użytkownik sam wywoła gcloud auth login, prawdopodobnie nie podejrzewa niczego.
Aby wylistować pliki na drive: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"
Jeśli atakujący ma pełny dostęp do GWS, będzie mógł uzyskać dostęp do grup z uprzywilejowanym dostępem do GCP lub nawet użytkowników, dlatego przejście z GWS do GCP jest zazwyczaj "prostsze", ponieważ użytkownicy w GWS mają wysokie uprawnienia w GCP.
Domyślnie użytkownicy mogą swobodnie dołączać do grup Workspace w Organizacji, a te grupy mogą mieć przypisane uprawnienia GCP (sprawdź swoje grupy w https://groups.google.com/).
Wykorzystując eskalację uprawnień google groups, możesz być w stanie eskalować do grupy z jakimś rodzajem uprzywilejowanego dostępu do GCP.
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)
