Polish - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP <--> Workspace Pivoting

Nauka hakowania AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia 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ź:

pageGCP - Understanding Domain-Wide Delegation

Skompromitowanie istniejącej delegacji

Jeśli atakujący zdobył pewne uprawnienia w 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ć wszystkie 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 znajomość jednego ważnego jest wystarczająca i konieczna do podawania się za niego. 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 żadnych uprawnień, 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 korzystając z 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, korzystając z 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 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 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 bearer dla każdego JWT i zweryfikuj token przy użyciu interfejsu API tokeninfo.

Skrypt Pythona Gitlaba

Gitlab stworzył ten skrypt Pythona, który może wykonać dwie rzeczy - wyświetlić katalog użytkowników 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 w GWS mógłby utworzyć nową delegację umożliwiającą kontom usługowym udawanie niektórych użytkowników GWS:

  1. Generowanie nowego konta usługowego i odpowiadającej pary kluczy: Na GCP, nowe zasoby kont usługowych można tworzyć interaktywnie za pomocą konsoli lub programistycznie 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ć programistycznie, 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 admina Google Workspace.

  1. Przywileje dołączania zakresów OAuth: Podczas konfigurowania nowej delegacji, Google wymaga tylko 2 parametrów, identyfikatora klienta, 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 konfigurowania 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 rolę Właściciela nad nim.

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:

pageGCP - IAM, Principals & Org Policies Enum

Nadużycie Gcloud

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

pageGCP - 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ć do 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, a 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

Dowiedz się, jak hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

PreviousGCP - Storage EnumNextGCP - Understanding Domain-Wide Delegation

Last updated