Polish - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP <--> Workspace Pivoting

Wesprzyj HackTricks

Z GCP do GWS

Podstawy Delegacji na Poziomie Domeny

Delegacja na poziomie domeny w Google Workspace pozwala obiektowi tożsamości, czy to zewnętrznej aplikacji z Google Workspace Marketplace, czy wewnętrznemu kontu usługi GCP, na dostęp do danych w całym Workspace w imieniu użytkowników.

Oznacza to w zasadzie, że konta usług w projektach GCP organizacji mogą podawać się za użytkowników Workspace tej samej organizacji (lub nawet z innej).

Aby uzyskać więcej informacji na temat tego, jak dokładnie to działa, sprawdź:

GCP - Understanding Domain-Wide Delegation

Skompromitowanie istniejącej delegacji

Jeśli atakujący zdobył dostęp do GCP i zna ważny adres e-mail użytkownika Workspace (najlepiej super administratora) firmy, mógłby wyliczyć wszystkie projekty, do których ma dostęp, wyliczyć wszystkie konta usług w projektach, sprawdzić, do których kont usług ma dostęp, i powtarzać te kroki z każdym kontem usługi, które może podawać się za niego. Dzięki listy wszystkich kont usług, do których ma dostęp, i listy adresów e-mail Workspace, atakujący mógłby próbować podawać się za użytkownika za pomocą każdego konta usługi.

Zauważ, że podczas konfigurowania delegacji na poziomie domeny nie jest wymagany użytkownik Workspace, dlatego wystarczy znać jeden ważny adres e-mail i jest on wymagany do podawania się za kogoś. Jednakże uprawnienia podawanego użytkownika będą wykorzystane, więc jeśli jest to Super Administrator, będziesz mógł uzyskać dostęp do wszystkiego. Jeśli nie ma żadnego dostępu, to będzie to bezużyteczne.

GCP Generate Delegation Token

Ten prosty skrypt wygeneruje token OAuth jako podany użytkownik, który następnie można użyć do 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. Wylicz projekty GCP za pomocą interfejsu API Resource Manager.

  2. Iteruj na każdym zasobie projektu i wylicz zasoby konta usługi GCP, do których początkowy użytkownik IAM ma dostęp, używając GetIAMPolicy.

  3. Iteruj na 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 posiada to uprawnienie z natury.

  4. Utwórz nowy prywatny klucz KEY_ALG_RSA_2048 dla każdego zasobu konta usługi, który został znaleziony z odpowiednim uprawnieniem w polityce IAM.

  5. Iteruj na każdym nowym koncie usługi i utwórz JWT obiekt dla niego, który składa się z poświadczeń prywatnego klucza 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 ze wszystkimi zakresami 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 określonego użytkownika, ważne jest zrozumienie, że DWD wpływa na każdą tożsamość w domenie. W rezultacie utworzenie JWT dla dowolnego użytkownika domeny wpływa na wszystkie tożsamości w tej domenie, zgodnie z naszą kontrolą enumeracji kombinacji. Po prostu mówiąc, jedno ważne konto Workspace jest wystarczające do kontynuacji. 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. Ważne jest (ponownie) zauważenie, że JWT są specyficzne dla domeny i nie są generowane dla każdego użytkownika; dlatego proces automatyczny kieruje się w stronę jednej unikalnej tożsamości na domenę.

  7. Wylicz i utwórz nowy token dostępu beara dla każdego JWT i zweryfikuj token za pomocą interfejsu API tokeninfo.

Skrypt Pythona Gitlaba

Gitlab stworzył ten skrypt Pythona, który może wykonać dwie rzeczy - wyświetlić katalog użytkownika i utworzyć nowe konto administracyjne, wskazując plik json z poświadczeniami SA i użytkownikiem do podrobienia. Oto jak 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ę (Trwałość)

Możliwe jest sprawdzenie Delegacji na Poziomie Domeny w https://admin.google.com/u/1/ac/owl/domainwidedelegation.

Atakujący mający zdolność tworzenia kont usługowych w projekcie GCP oraz uprawnienia super administratora do GWS może utworzyć nową delegację, pozwalającą kontom usługowym na podszywanie się pod niektórych użytkowników GWS:

  1. Generowanie nowego konta usługowego i odpowiadającej pary kluczy: Na platformie GCP, nowe zasoby kont usługowych można tworzyć interaktywnie za pomocą konsoli lub programowo przy użyciu bezpośrednich wywołań interfejsu API i narzędzi CLI. Wymaga to roli iam.serviceAccountAdmin lub dowolnej niestandardowej roli wyposażonej w uprawnienie iam.serviceAccounts.create. Po utworzeniu konta usługowego przejdziemy do wygenerowania powiązanej pary kluczy (uprawnienie iam.serviceAccountKeys.create).

  2. Utworzenie nowej delegacji: Ważne jest zrozumienie, że tylko rola Super Administratora posiada zdolność do ustawienia globalnej delegacji na Poziomie Domeny w Google Workspace i delegację na Poziomie Domeny nie można skonfigurować programowo, Można ją jedynie utworzyć i dostosować ręcznie za pomocą konsoli Google Workspace.

  • Utworzenie reguły można znaleźć na stronie Kontrole API → Zarządzaj Delegacją na Poziomie Domeny w konsoli administratora Google Workspace.

  1. Przypisanie uprawnień zakresu OAuth: Podczas konfigurowania nowej delegacji, Google wymaga tylko 2 parametrów, identyfikatora klienta (Client ID), który jest ID OAuth zasobu Konta Usługowego GCP, oraz zakresów OAuth, które określają, jakie wywołania API są wymagane przez delegację.

  • Pełną listę zakresów OAuth można znaleźć 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: W tym momencie mamy działający obiekt zdelegowany w GWS. Teraz, korzystając z prywatnego klucza konta usługowego GCP, możemy wykonywać wywołania API (w zakresie określonym w parametrze zakresu OAuth) w celu jego uruchomienia i działania w imieniu dowolnej tożsamości istniejącej w Google Workspace. Jak się dowiedzieliśmy, konto usługowe będzie generować tokeny dostępu zgodnie z własnymi potrzebami i zgodnie z uprawnieniami, jakie ma do aplikacji REST API.

  • Sprawdź poprzednią sekcję w celu uzyskania narzędzi do korzystania z tej delegacji.

Delegacja Międzyorganizacyjna

ID OAuth konta usługowego jest globalne i może być używane do delegacji międzyorganizacyjnej. Nie zostało wprowadzone żadne ograniczenie uniemożliwiające delegację międzyglobalną. W prostych słowach, konta usługowe z różnych organizacji GCP mogą być używane do skonfigurowania delegacji na poziomie domeny w innych organizacjach Workspace. Spowoduje to, że wystarczy dostęp Super Administratora do Workspace, a nie dostęp do tego samego konta GCP, ponieważ przeciwnik może tworzyć konta usługowe i klucze prywatne w swoim osobiście kontrolowanym koncie GCP.

Tworzenie projektu w celu wyliczenia Workspace

Domyślnie użytkownicy Workspace mają uprawnienia do tworzenia nowych projektów, a gdy tworzony jest nowy projekt, twórca otrzymuje nad nim rolę Właściciela.

Dlatego użytkownik może utworzyć projekt, włączyć interfejsy API do wyliczenia Workspace w swoim nowym projekcie i spróbować go wyliczyć.

Aby użytkownik mógł wyliczyć Workspace, potrzebuje również wystarczających uprawnień Workspace (nie każdy użytkownik będzie w stanie wyliczyć 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 wyliczeń w:

GCP - IAM, Principals & Org Policies Enum

Nadużycie Gcloud

Możesz znaleźć dalsze informacje na temat przepływu gcloud do logowania się w:

GCP - Non-svc Persistance

Jak wyjaśniono tam, 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 skompromitowałeś fizycznie komputer użytkownika i użytkownik nadal jest zalogowany na swoje konto, możesz zalogować się, generując token z dostępem do dysku za pomocą:

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ć w CLOUDSDK_SCOPES zakres 'https://www.googleapis.com/auth/drive':

W związku z tym, 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 wywoła polecenie gcloud auth login, prawdopodobnie nie podejrzewa niczego.

Aby wyświetlić pliki dysku: 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 przechodzenie z GWS do GCP jest zazwyczaj bardziej "proste", ponieważ użytkownicy w GWS mają wysokie uprawnienia w GCP.

Eskalacja uprawnień w grupach Google

Domyślnie użytkownicy mogą swobodnie dołączać do grup Workspace w Organizacji i te grupy mogą mieć przypisane uprawnienia GCP (sprawdź swoje grupy na https://groups.google.com/).

Wykorzystując google groups privesc, możesz być w stanie eskalować do grupy z pewnym rodzajem uprzywilejowanego dostępu do GCP.

Odnośniki

Wesprzyj HackTricks
PreviousGCP - Workflows EnumNextGCP - Understanding Domain-Wide Delegation

Last updated