GCP - Basic Information
Last updated
Last updated
Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Google Cloud koristi Hijerarhiju resursa koja je konceptualno slična tradicionalnom fajl sistemu. Ovo pruža logički radni tok roditelj/dete sa specifičnim tačkama vezivanja za politike i dozvole.
Na visokom nivou, izgleda ovako:
A virtual machine (called a Compute Instance) is a resource. A resource resides in a project, probably alongside other Compute Instances, storage buckets, etc.
Moguće je migrirati projekat bez organizacije u organizaciju sa dozvolama roles/resourcemanager.projectCreator i roles/resourcemanager.projectMover. Ako je projekat unutar druge organizacije, potrebno je kontaktirati GCP podršku da ih prvo premeste iz organizacije. Za više informacija pogledajte ovo.
Omogućavaju centralizaciju kontrole nad resursima vaše organizacije u oblaku:
Centralizujte kontrolu da konfigurišete ograničenja o tome kako se resursi vaše organizacije mogu koristiti.
Definišite i uspostavite ograničenja za vaše razvojne timove da ostanu unutar granica usklađenosti.
Pomozite vlasnicima projekata i njihovim timovima da brzo napreduju bez brige o kršenju usklađenosti.
Ove politike mogu biti kreirane da uticaju na celu organizaciju, folder(e) ili projekat(e). Potomci ciljanog čvora hijerarhije resursa nasleđuju politiku organizacije.
Da biste definisali politiku organizacije, birate ograničenje, što je određena vrsta ograničenja prema Google Cloud usluzi ili grupi Google Cloud usluga. Konfigurišete to ograničenje sa željenim ograničenjima.
Ograničite deljenje resursa na osnovu domena.
Ograničite korišćenje naloga za upravljanje identitetom i pristupom.
Ograničite fizičku lokaciju novokreiranih resursa.
Onemogućite kreiranje naloga usluga.
Postoji mnogo drugih ograničenja koja vam daju preciznu kontrolu nad resursima vaše organizacije. Za više informacija, pogledajte spisak svih ograničenja politike organizacije.
Ove su slične IAM politikama u AWS-u jer svaka uloga sadrži skup dozvola.
Međutim, za razliku od AWS-a, ne postoji centralizovani repozitorij uloga. Umesto toga, resursi daju X pristupne uloge Y principima, a jedini način da saznate ko ima pristup resursu je korišćenje get-iam-policy metode nad tim resursom.
To može biti problem jer to znači da je jedini način da saznate koje dozvole princip ima da pitate svaki resurs kome dodeljuje dozvole, a korisnik možda neće imati dozvole da dobije dozvole od svih resursa.
Postoje tri tipa uloga u IAM:
Osnovne/Primitivne uloge, koje uključuju Vlasnika, Urednika i Gledaoca uloge koje su postojale pre uvođenja IAM-a.
Predefinisane uloge, koje pružaju granularan pristup za određenu uslugu i kojima upravlja Google Cloud. Postoji mnogo predefinisanih uloga, možete videti sve njih sa privilegijama koje imaju ovde.
Prilagođene uloge, koje pružaju granularan pristup prema listi dozvola koju je odredio korisnik.
Postoje hiljade dozvola u GCP-u. Da biste proverili da li uloga ima dozvolu, možete pretražiti dozvolu ovde i videti koje uloge je imaju.
Takođe možete pretražiti ovde predefinisane uloge koje nudi svaki proizvod. Imajte na umu da neke uloge ne mogu biti dodeljene korisnicima i samo SAs zbog nekih dozvola koje sadrže. Pored toga, imajte na umu da će dozvole imati efekat samo ako su priključene relevantnoj usluzi.
Ili proverite da li prilagođena uloga može koristiti određenu dozvolu ovde.
GCP - IAM, Principals & Org Policies EnumU GCP konzoli ne postoji upravljanje Korisnicima ili Grupama, to se obavlja u Google Workspace. Iako možete sinhronizovati različitog provajdera identiteta u Google Workspace.
Možete pristupiti korisnicima i grupama Workspace-a na https://admin.google.com.
MFA može biti prinudna za korisnike Workspace-a, međutim, napadač može koristiti token za pristup GCP-u putem CLI-a koji neće biti zaštićen MFA (biće zaštićen MFA samo kada se korisnik prijavi da ga generiše: gcloud auth login).
Kada se organizacija kreira, nekoliko grupa je snažno preporučeno da se kreiraju. Ako upravljate bilo kojom od njih, mogli biste kompromitovati sve ili važan deo organizacije:
Grupa
Funkcija
gcp-organization-admins
(grupa ili pojedinačni nalozi potrebni za kontrolnu listu)
Upravljanje bilo kojim resursom koji pripada organizaciji. Dodelite ovu ulogu štedljivo; administratori organizacije imaju pristup svim vašim Google Cloud resursima. Alternativno, s obzirom na to da je ova funkcija visoko privilegovana, razmislite o korišćenju pojedinačnih naloga umesto kreiranja grupe.
gcp-network-admins
(potrebno za kontrolnu listu)
Kreiranje mreža, podmreža, pravila vatrozida i mrežnih uređaja kao što su Cloud Router, Cloud VPN i cloud load balancers.
gcp-billing-admins
(potrebno za kontrolnu listu)
Postavljanje računa za naplatu i praćenje njihove upotrebe.
gcp-developers
(potrebno za kontrolnu listu)
Dizajniranje, kodiranje i testiranje aplikacija.
gcp-security-admins
Uspostavljanje i upravljanje sigurnosnim politikama za celu organizaciju, uključujući upravljanje pristupom i politike ograničenja organizacije. Pogledajte vodič za sigurnosne osnove Google Clouda za više informacija o planiranju vaše Google Cloud sigurnosne infrastrukture.
gcp-devops
Kreiranje ili upravljanje end-to-end procesima koji podržavaju kontinuiranu integraciju i isporuku, praćenje i sistemsko obezbeđenje.
gcp-logging-admins
gcp-logging-viewers
gcp-monitor-admins
gcp-billing-viewer
(više nije podrazumevano)
Praćenje troškova na projektima. Tipični članovi su deo finansijskog tima.
gcp-platform-viewer
(više nije podrazumevano)
Pregled informacija o resursima širom Google Cloud organizacije.
gcp-security-reviewer
(više nije podrazumevano)
Pregled sigurnosti u oblaku.
gcp-network-viewer
(više nije podrazumevano)
Pregled konfiguracija mreže.
grp-gcp-audit-viewer
(više nije podrazumevano)
Pregledanje revizorskih logova.
gcp-scc-admin
(više nije podrazumevano)
Upravljanje Security Command Center-om.
gcp-secrets-admin
(više nije podrazumevano)
Upravljanje tajnama u Secret Manager-u.
Sprovodite jake lozinke
Između 8 i 100 karaktera
Bez ponovne upotrebe
Bez isteka
Ako ljudi pristupaju Workspace-u putem treće strane, ovi zahtevi se ne primenjuju.
Ovo su principi koje resursi mogu imati priključene i pristupiti kako bi lako interagovali sa GCP-om. Na primer, moguće je pristupiti auth tokenu naloga usluga priključenog na VM u metapodacima.
Moguće je naići na neke sukobe kada se koriste i IAM i pristupne oblasti. Na primer, vaš nalog usluga može imati IAM ulogu compute.instanceAdmin, ali instanca koju ste kompromitovali ima ograničenje opsega https://www.googleapis.com/auth/compute.readonly. Ovo bi vam onemogućilo da napravite bilo kakve promene koristeći OAuth token koji je automatski dodeljen vašoj instanci.
Slično je IAM ulogama iz AWS-a. Ali ne kao u AWS-u, bilo koji nalog usluga može biti priključen bilo kojoj usluzi (ne mora to dozvoliti putem politike).
Nekoliko naloga usluga koje ćete pronaći zapravo su automatski generisani od strane GCP-a kada počnete koristiti uslugu, kao:
Međutim, takođe je moguće kreirati i povezati se sa resursima prilagođenim servisnim nalozima, koji će izgledati ovako:
Postoje 2 glavna načina za pristup GCP kao servisni nalog:
Putem OAuth tokena: Ovo su tokeni koje ćete dobiti sa mesta kao što su metapodaci ili krađom http zahteva i ograničeni su opsegom pristupa.
Ključevi: Ovo su javni i privatni parovi ključeva koji će vam omogućiti da potpišete zahteve kao servisni nalog i čak generišete OAuth tokene za izvršavanje akcija kao servisni nalog. Ovi ključevi su opasni jer ih je teže ograničiti i kontrolisati, zato GCP preporučuje da ih ne generišete.
Imajte na umu da svaki put kada se kreira SA, GCP generiše ključ za servisni nalog kojem korisnik ne može pristupiti (i neće biti naveden u web aplikaciji). Prema ovoj temi ovaj ključ se interno koristi od strane GCP da omogući metapodacima pristup za generisanje dostupnih OAuth tokena.
Opsezi pristupa su priključeni generisanim OAuth tokenima za pristup GCP API krajnjim tačkama. Oni ograničavaju dozvole OAuth tokena. To znači da ako token pripada vlasniku resursa, ali nema u opsegu tokena pristup tom resursu, token ne može biti korišćen za (zlo)upotrebu tih privilegija.
Google zapravo preporučuje da opsezi pristupa ne budu korišćeni i da se potpuno oslanjaju na IAM. Web portal za upravljanje zapravo to sprovodi, ali opsezi pristupa se i dalje mogu primeniti na instance koristeći prilagođene servisne naloge programatski.
Možete videti koji su opsezi dodeljeni upitom:
Prethodni opseg su oni generisani podrazumevano koristeći gcloud za pristup podacima. To je zato što kada koristite gcloud prvo kreirate OAuth token, a zatim ga koristite za kontaktiranje krajnjih tačaka.
Najvažniji opseg od onih potencijalno je cloud-platform, što u suštini znači da je moguće pristupiti bilo kojoj usluzi u GCP.
Možete pronaći listu svi mogući opsezi ovde.
Ako imate gcloud kredencijale za pretraživač, moguće je dobiti token sa drugim opsezima, radeći nešto poput:
Kao što je definisano od strane terraform-a u https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam, korišćenjem terraform-a sa GCP postoje različiti načini za dodeljivanje pristupa principalu nad resursom:
Članstva: Postavljate principale kao članove uloga bez ograničenja nad ulogom ili principima. Možete staviti korisnika kao člana uloge, a zatim staviti grupu kao člana iste uloge i takođe postaviti te principe (korisnika i grupu) kao članove drugih uloga.
Povezivanja: Nekoliko principala može biti povezano sa ulogom. Ti principali mogu i dalje biti povezani ili članovi drugih uloga. Međutim, ako je principal koji nije povezan sa ulogom postavljen kao član povezane uloge, sledeći put kada se povezivanje primeni, članstvo će nestati.
Politike: Politika je autoritativna, ukazuje na uloge i principe i tada, ti principi ne mogu imati više uloga i te uloge ne mogu imati više principa osim ako ta politika nije izmenjena (čak ni u drugim politikama, povezivanjima ili članstvima). Stoga, kada je uloga ili principal specificiran u politici, sve njegove privilegije su ograničene tom politikom. Očigledno, ovo se može zaobići u slučaju da principal dobije opciju da izmeni politiku ili dozvole za eskalaciju privilegija (kao što je kreiranje novog principa i povezivanje njega sa novom ulogom).
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
