Polish - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP - Basic Information

Zacznij od zera i stań się ekspertem od hakowania AWS dzięki htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Hierarchia zasobów

Google Cloud używa hierarchii zasobów, która jest podobna, koncepcyjnie, do tradycyjnego systemu plików. Zapewnia to logiczny przepływ rodzic/dziecko z określonymi punktami dołączenia polityk i uprawnień.

W ogólnym zarysie wygląda to tak:

Organization
--> Folders
--> Projects
--> Resources

Maszyna wirtualna (zwana instancją obliczeniową) jest zasobem. Zasób znajduje się w projekcie, prawdopodobnie obok innych instancji obliczeniowych, kubełków na przechowywanie itp.

Migracja projektów

Możliwa jest migracja projektu bez żadnej organizacji do organizacji z uprawnieniami roles/resourcemanager.projectCreator i roles/resourcemanager.projectMover. Jeśli projekt znajduje się w innej organizacji, należy skontaktować się z pomocą techniczną GCP, aby przenieść go najpierw poza organizację. Aby uzyskać więcej informacji, sprawdź to.

Zasady organizacji

Pozwalają na scentralizowaną kontrolę nad zasobami chmurowymi Twojej organizacji:

  • Skoncentruj kontrolę, aby skonfigurować ograniczenia dotyczące sposobu wykorzystywania zasobów Twojej organizacji.

  • Zdefiniuj i ustanów bariery ochronne dla zespołów deweloperskich, aby pozostać w granicach zgodności.

  • Pomóż właścicielom projektów i ich zespołom działać szybko, nie martwiąc się o naruszenie zgodności.

Te zasady mogą być tworzone, aby dotyczyć całej organizacji, folderów lub projektów. Potomkowie docelowego węzła hierarchii zasobów dziedziczą zasady organizacji.

Aby zdefiniować zasadę organizacji, wybierasz ograniczenie, które jest określonym typem ograniczenia dotyczącego usługi Google Cloud lub grupy usług Google Cloud. Następnie konfigurujesz to ograniczenie z wymaganymi ograniczeniami.

Powszechne przypadki użycia

  • Ograniczenie udostępniania zasobów na podstawie domeny.

  • Ograniczenie używania kont usługowych tożsamości i dostępu.

  • Ograniczenie fizycznego położenia nowo tworzonych zasobów.

  • Wyłączenie tworzenia kont usługowych.

Istnieje wiele innych ograniczeń, które pozwalają na precyzyjną kontrolę zasobów Twojej organizacji. Aby uzyskać więcej informacji, zobacz listę wszystkich ograniczeń usługi Zasady Organizacji.

Domyślne zasady organizacji

To są zasady, które Google doda domyślnie podczas konfigurowania Twojej organizacji GCP:

Zasady zarządzania dostępem

  • Ograniczone kontakty domenowe: Zapobiega dodawaniu użytkowników do Kontaktów Istotnych poza określonymi domenami. Ogranicza Kontakty Istotne, aby umożliwiały tylko zarządzane tożsamości użytkowników w wybranych domenach otrzymywać powiadomienia platformowe.

  • Ograniczone udostępnianie domenowe: Zapobiega dodawaniu użytkowników do polityk IAM poza określonymi domenami. Ogranicza polityki IAM, aby umożliwiały tylko zarządzane tożsamości użytkowników w wybranych domenach uzyskać dostęp do zasobów w tej organizacji.

  • Zapobieganie publicznemu dostępowi: Zapobiega ujawnianiu kubełków Cloud Storage publicznie. Zapewnia, że deweloper nie może skonfigurować kubełków Cloud Storage tak, aby miały nieuwierzytelniony dostęp do internetu.

  • Jednolity dostęp na poziomie kubełka: Zapobiega listom kontroli dostępu na poziomie obiektu (ACL) w kubełkach Cloud Storage. Ułatwia zarządzanie dostępem, stosując polityki IAM konsekwentnie we wszystkich obiektach w kubełkach Cloud Storage.

  • Wymagaj logowania do systemu operacyjnego: Maszyny wirtualne tworzone w nowych projektach będą miały włączone logowanie do systemu operacyjnego. Pozwala to zarządzać dostępem SSH do instancji za pomocą IAM, bez konieczności tworzenia i zarządzania indywidualnymi kluczami SSH.

Dodatkowe zasady bezpieczeństwa dla kont usługowych

  • Wyłącz automatyczne przyznawanie uprawnień IAM: Zapobiega automatycznemu przyznawaniu domyślnych kont usługowych App Engine i Compute Engine roli Redaktora IAM w projekcie podczas tworzenia. Zapewnia to, że konta usługowe nie otrzymują zbyt obszernych ról IAM podczas tworzenia.

  • Wyłącz tworzenie kluczy kont usługowych: Zapobiega tworzeniu publicznych kluczy kont usługowych. Pomaga to zmniejszyć ryzyko ujawnienia trwałych poświadczeń.

  • Wyłącz przesyłanie kluczy kont usługowych: Zapobiega przesyłaniu publicznych kluczy kont usługowych. Pomaga to zmniejszyć ryzyko ujawnienia lub ponownego wykorzystania materiału klucza.

Zasady konfiguracji bezpiecznej sieci VPC

  • Zdefiniuj dozwolone zewnętrzne adresy IP dla instancji VM: Zapobiega tworzeniu instancji obliczeniowych z publicznym adresem IP, co może je wystawić na ruch internetowy.

  • Wyłącz zagnieżdżanie wirtualizacji VM: Zapobiega tworzeniu zagnieżdzonych maszyn wirtualnych na maszynach wirtualnych Compute Engine. Zmniejsza to ryzyko bezpieczeństwa związane z posiadaniem nienadzorowanych zagnieżdzonych maszyn wirtualnych.

  • Wyłącz port szeregowy VM: Zapobiega dostępowi do portu szeregowego maszyn wirtualnych Compute Engine. Zapobiega to wprowadzaniu danych wejściowych do portu szeregowego serwera za pomocą interfejsu API Compute Engine.

  • Ogranicz sieci autoryzowane na instancje Cloud SQL: Zapobiega publicznym lub niezewnętrznym zakresom sieciowym dostępu do baz danych Cloud SQL.

  • Ogranicz przekazywanie protokołu na podstawie typu adresu IP: Zapobiega przekazywaniu protokołu VM dla zewnętrznych adresów IP.

  • Ogranicz dostęp do publicznego IP na instancje Cloud SQL: Zapobiega tworzeniu instancji Cloud SQL z publicznym adresem IP, co może je wystawić na ruch internetowy.

  • Ogranicz usuwanie zablokowania projektu VPC współdzielonego: Zapobiega przypadkowemu usunięciu projektów hostujących VPC współdzielone.

  • Ustawia ustawienie wewnętrznego DNS dla nowych projektów na Zonalne DNS Only: Zapobiega korzystaniu z ustawienia DNS z ograniczoną dostępnością usługi.

  • Pomiń domyślne tworzenie sieci: Zapobiega automatycznemu tworzeniu domyślnej sieci VPC i powiązanych zasobów. Zapobiega to nadmiernie obszernym domyślnym regułom zapory sieciowej.

  • Wyłączanie używania zewnętrznego IPv6 w sieci VPC: Zapobiega tworzeniu zewnętrznych podsieci IPv6, które mogą być narażone na nieautoryzowany dostęp do internetu.

Role IAM

Są one podobne do polityk IAM w AWS, ponieważ każda rola zawiera zestaw uprawnień.

Jednak w odróżnieniu od AWS, nie ma centralnego repozytorium ról. Zamiast tego, zasoby nadają role dostępu X do zasobów Y, a jedynym sposobem dowiedzenia się, kto ma dostęp do zasobu, jest użycie metody get-iam-policy na tym zasobie. Może to być problemem, ponieważ oznacza to, że jedynym sposobem dowiedzenia się, jakie uprawnienia ma dany podmiot, jest zapytanie każdego zasobu, komu nadaje uprawnienia, a użytkownik może nie mieć uprawnień do uzyskania uprawnień od wszystkich zasobów.

Istnieją trzy rodzaje ról w IAM:

  • Podstawowe/ pierwotne role, które obejmują role Właściciela, Redaktora i Oglądającego, które istniały przed wprowadzeniem IAM.

  • Role predefiniowane, które zapewniają szczegółowy dostęp do określonej usługi i są zarządzane przez Google Cloud. Istnieje wiele predefiniowanych ról, możesz zobaczyć je wszystkie wraz z uprawnieniami, jakie mają tutaj.

  • Role niestandardowe, które zapewniają szczegółowy dostęp zgodnie z listą uprawnień określoną przez użytkownika.

W GCP istnieje tysiące uprawnień. Aby sprawdzić, czy rola ma określone uprawnienia, możesz wyszukać uprawnienie tutaj i zobaczyć, które role je mają.

Możesz również wyszukać tutaj predefiniowane role oferowane przez każdy produkt. Zauważ, że niektóre role nie mogą być przypisane użytkownikom, a tylko do kont usługowych z powodu zawartych w nich uprawnień. Ponadto zauważ, że uprawnienia będą miały zastosowanie tylko wtedy, gdy zostaną przypisane do odpowiedniej usługi.

Lub sprawdź, czy niestandardowa rola może używać konkretnej uprawnienia tutaj.

Użytkownicy

W konsoli GCP nie ma zarządzania Użytkownikami ani Grupami, to jest wykonywane w Google Workspace. Możesz jednak zsynchronizować inny dostawcę tożsamości w Google Workspace.

Możesz uzyskać dostęp do użytkowników i grup Workspace na https://admin.google.com.

MFA może być wymuszone dla użytkowników Workspace, jednak atakujący może użyć tokena do dostępu do GCP za pomocą wiersza poleceń, który nie będzie chroniony przez MFA (będzie chroniony przez MFA tylko wtedy, gdy użytkownik się zaloguje, aby go wygenerować: gcloud auth login).

Grupy

Kiedy organizacja jest tworzona, zaleca się stworzenie kilku grup. Jeśli zarządzasz którąkolwiek z nich, możesz narazić całą organizację lub jej ważną część:

Domyślna polityka hasła

  • Wymuszaj silne hasła

  • Od 8 do 100 znaków

  • Brak ponownego użycia

  • Brak wygaśnięcia

  • Jeśli ludzie uzyskują dostęp do Workspace za pośrednictwem dostawcy zewnętrznego, te wymagania nie są stosowane.

Konta usług

Są to podmioty, które zasoby mogą mieć przypisane i uzyskiwać dostęp do interakcji z GCP. Na przykład możliwe jest uzyskanie tokena uwierzytelniającego Konta Usługi przypisanego do VM w metadanych. Możliwe jest napotkanie konfliktów podczas korzystania zarówno z IAM, jak i zakresów dostępu. Na przykład twoje konto usługi może mieć rolę IAM compute.instanceAdmin, ale instancja, którą naruszyłeś, została ograniczona zakresem https://www.googleapis.com/auth/compute.readonly. Spowoduje to brak możliwości dokonywania zmian za pomocą tokena OAuth, który automatycznie jest przypisany do twojej instancji.

To jest podobne do ról IAM z AWS. Jednak w odróżnieniu od AWS, dowolne konto usługi może być przypisane do dowolnej usługi (nie musi być do tego uprawnione za pomocą polityki).

Wiele kont usług, które znajdziesz, jest tak naprawdę automatycznie generowanych przez GCP podczas korzystania z usługi, takich jak:

PROJECT_NUMBER-compute@developer.gserviceaccount.com
PROJECT_ID@appspot.gserviceaccount.com

Jednakże istnieje także możliwość utworzenia i dołączenia do zasobów niestandardowych kont usług, które będą wyglądać tak:

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

Zakresy dostępu

Zakresy dostępu są dołączone do wygenerowanych tokenów OAuth w celu uzyskania dostępu do punktów końcowych interfejsu API GCP. Ograniczają one uprawnienia tokena OAuth. Oznacza to, że jeśli token należy do Właściciela zasobu, ale nie ma w zakresie tego zasobu, token nie może być użyty do (nadużywania) tych uprawnień.

Google faktycznie zaleca, aby nie używać zakresów dostępu i całkowicie polegać na IAM. Portal zarządzania internetowego faktycznie to narzuca, ale zakresy dostępu mogą nadal być stosowane do instancji za pomocą niestandardowych kont usług programistycznie.

Możesz zobaczyć, jakie zakresy są przypisane, kwerując:

curl 'https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=<access_token>'

{
"issued_to": "223044615559.apps.googleusercontent.com",
"audience": "223044615559.apps.googleusercontent.com",
"user_id": "139746512919298469201",
"scope": "openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/appengine.admin https://www.googleapis.com/auth/sqlservice.login https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/accounts.reauth",
"expires_in": 2253,
"email": "username@testing.com",
"verified_email": true,
"access_type": "offline"
}

Poprzednie zakresy są generowane domyślnie przy użyciu gcloud do uzyskania dostępu do danych. Dzieje się tak dlatego, że przy użyciu gcloud najpierw tworzony jest token OAuth, a następnie jest on używany do kontaktowania się z punktami końcowymi.

Najważniejszym zakresem z tych potencjalnych jest cloud-platform, co w zasadzie oznacza, że jest możliwe uzyskanie dostępu do dowolnej usługi w GCP.

Możesz znaleźć listę wszystkich możliwych zakresów tutaj.

Jeśli masz poświadczenia przeglądarki gcloud, możliwe jest uzyskanie tokenu z innymi zakresami, wykonując coś w rodzaju:

# Maybe you can get a user token with other scopes changing the scopes array from ~/.config/gcloud/credentials.db

# Set new scopes for SDKs credentials
gcloud auth application-default login --scopes=https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/sqlservice.login,https://www.googleapis.com/auth/appengine.admin,https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/accounts.reauth,https://www.googleapis.com/auth/admin.directory.user,https://www.googleapis.com/auth/admin.directory.group,https://www.googleapis.com/auth/admin.directory.domain,https://www.googleapis.com/auth/admin.directory.user

# Print new token
gcloud auth application-default print-access-token

# To use this token with some API you might need to use curl to indicate the project header with --header "X-Goog-User-Project: <project-name>"

Polityki IAM, Wiązania i Członkostwa Terraform

Zdefiniowane przez terraform w https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam korzystając z terraform z GCP istnieją różne sposoby przyznawania dostępu głównemu do zasobu:

  • Członkostwa: Ustawiasz głównych jako członków ról bez ograniczeń dotyczących roli lub głównych. Możesz dodać użytkownika jako członka roli, a następnie dodać grupę jako członka tej samej roli oraz ustawić te główne (użytkownika i grupę) jako członków innych ról.

  • Wiązania: Kilka głównych może być powiązanych z rolą. Te główne mogą nadal być powiązane lub być członkami innych ról. Jednakże, jeśli główny, który nie jest powiązany z rolą, zostanie ustawiony jako członek powiązanej roli, to przy następnym zastosowaniu wiązania, członkostwo zniknie.

  • Polityki: Polityka jest wiążąca, określa role i główne, a następnie te główne nie mogą mieć więcej ról, a te role nie mogą mieć więcej głównych chyba że polityka zostanie zmodyfikowana (nawet w innych politykach, wiązaniach lub członkostwach). Dlatego, gdy rola lub główny jest określony w polityce, wszystkie jego uprawnienia są ograniczone przez tę politykę. Oczywiście, można to obejść w przypadku, gdy główny otrzyma możliwość modyfikacji polityki lub uprawnień eskalacji uprawnień (np. utworzenie nowego głównego i przypisanie mu nowej roli).

Odnośniki

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

Inne sposoby wsparcia HackTricks:

PreviousGCP PentestingNextGCP - Federation Abuse

Last updated