Polish - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

GCP <--> Workspace Pivoting

Support HackTricks

From GCP to GWS

Podstawy delegacji w całej domenie

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 impersonować 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 Delegation

Kompromitacja istniejącej delegacji

Jeśli atakujący skomprymował 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órego może impersonować. 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ć impersonować 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ć jeden ważny, aby było to możliwe. Jednak uprawnienia impersonowanego 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.

GCP Generuj token delegacji

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:

# Impersonate indicated user
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file>

# Impersonate indicated user and add additional scopes
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file> --scopes "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"

DeleFriend

To jest narzędzie, które może przeprowadzić atak, wykonując następujące kroki:

  1. Enumerate GCP Projects przy użyciu Resource Manager API.

  2. Iterować 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.

  3. Iterować po każdej roli konta usługi i znaleźć 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.

  4. Utworzyć 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.

  5. Iterować po każdym nowym koncie usługi i utworzyć 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.

  6. 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ę.

  7. Enumerate and create a new bearer access token dla każdego JWT i zweryfikować token za pomocą tokeninfo API.

Gitlab's Python script

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ć:

# Install requirements
pip install --upgrade --user oauth2client

# Validate access only
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com

# List the directory
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--list

# Create a new admin account
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--account pwned

Utwórz nową delegację (Utrzymywanie)

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:

  1. 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).

  2. 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.

  1. 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

  1. 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.

Delegacja międzyorganizacyjna

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.

Tworzenie projektu do enumeracji Workspace

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).

# Create project
gcloud projects create <uniq-projec-name> --name=proj-name
# Set project
gcloud config set project <uniq-projec-name>
# Enable svcs
gcloud services enable admin.googleapis.com
gcloud services enable cloudidentity.googleapis.com
# Get org ID
gcloud organizations list
# Get currents email user groups (at least you can check the groups and members of the groups you belong to)
gcloud identity groups memberships search-transitive-groups --member-email <email> --labels=cloudidentity.googleapis.com/groups.discussion_forum
gcloud identity groups memberships list --group-email=g<group-email>

# FROM HERE THE USER NEEDS TO HAVE ENOUGH WORKSPACE ACCESS
gcloud beta identity groups preview --customer <org-cust-id>

Sprawdź więcej enumeracji w:

GCP - IAM, Principals & Org Policies Enum

Wykorzystywanie poświadczeń Gcloud

Możesz znaleźć więcej informacji na temat przepływu gcloud do logowania w:

GCP - Token Persistance

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:

gcloud auth login --enable-gdrive-access

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"

Z GWS do GCP

Dostęp do uprzywilejowanych użytkowników GCP

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.

Eskalacja uprawnień Google Groups

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.

Referencje

Wsparcie dla HackTricks
PreviousGCP - Workflows EnumNextGCP - Understanding Domain-Wide Delegation

Last updated