Serbian - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

GCP - Basic Information

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

Hijerarhija resursa

Google Cloud koristi Hijerarhiju resursa koja je konceptualno slična tradicionalnom sistemskom fajl sistemu. Ovo pruža logičan roditeljski/detinjasti radni tok sa specifičnim tačkama pričvršćivanja za politike i dozvole.

Na visokom nivou, izgleda ovako:

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

Projekti Migracija

Moguće je migrirati projekat bez bilo koje 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 izmesti iz organizacije. Za više informacija pogledajte ovde.

Politike Organizacije

Omogućavaju centralizovanu kontrolu nad resursima u vašoj organizaciji u oblaku:

  • Centralizovana kontrola za konfigurisanje ograničenja o tome kako se resursi vaše organizacije mogu koristiti.

  • Definisanje i uspostavljanje zaštitnih ograda za vaše razvojne timove kako bi ostali unutar granica usaglašenosti.

  • Pomažu vlasnicima projekata i njihovim timovima da brzo napreduju bez brige o kršenju usaglašenosti.

Ove politike mogu biti kreirane da utiču na celu organizaciju, folder(e) ili projekat(e). Potomci ciljanog čvora hijerarhije resursa nasleđuju politiku organizacije.

Da biste definisali politiku organizacije, izaberete ograničenje, koje je određeni tip ograničenja protiv bilo koje Google Cloud usluge ili grupe Google Cloud usluga. Zatim konfigurišete to ograničenje sa željenim ograničenjima.

Česti slučajevi upotrebe

  • Ograničavanje deljenja resursa na osnovu domena.

  • Ograničavanje korišćenja servisnih naloga za identitet i pristup.

  • Ograničavanje fizičke lokacije novostvorenih resursa.

  • Onemogućavanje kreiranja servisnih naloga.

Podrazumevane Politike Organizacije

Ovo su politike koje će Google automatski dodati prilikom postavljanja vaše GCP organizacije:

Politike Upravljanja Pristupom

  • Ograničeni kontakti domena: Onemogućava dodavanje korisnika Essential kontakata van vaših odabranih domena. Ovo ograničava Essential kontakte da dozvoli samo upravljane korisničke identitete u vašim odabranim domenima da primaju obaveštenja platforme.

  • Ograničeno deljenje domena: Onemogućava dodavanje korisnika u IAM politike van vaših odabranih domena. Ovo ograničava IAM politike da dozvoli samo upravljane korisničke identitete u vašim odabranim domenima da pristupe resursima unutar ove organizacije.

  • Prevencija javnog pristupa: Onemogućava Cloud Storage kante da budu izložene javnosti. Ovo osigurava da programer ne može konfigurisati Cloud Storage kante da imaju neautentifikovan pristup internetu.

  • Jednaki pristup nivou kante: Onemogućava liste kontrole pristupa na nivou objekta (ACL) u Cloud Storage kantama. Ovo pojednostavljuje upravljanje pristupom primenom IAM politika dosledno na sve objekte u Cloud Storage kantama.

  • Zahtevaj prijavljivanje na OS: Virtuelne mašine kreirane u novim projektima će imati omogućeno prijavljivanje na OS. Ovo vam omogućava da upravljate SSH pristupom vašim instancama koristeći IAM bez potrebe za kreiranjem i upravljanjem pojedinačnim SSH ključevima.

Dodatne sigurnosne politike za servisne naloge

  • Onemogući automatske IAM dozvole: Onemogućava podrazumevane App Engine i Compute Engine servisne naloge da automatski dobiju Editor IAM ulogu na projektu prilikom kreiranja. Ovo osigurava da servisni nalozi ne dobijaju preterano dozvoljene IAM uloge prilikom kreiranja.

  • Onemogući kreiranje ključeva servisnog naloga: Onemogućava kreiranje javnih ključeva servisnih naloga. Ovo pomaže u smanjenju rizika izlaganja trajnih akreditiva.

  • Onemogući otpremanje ključeva servisnog naloga: Onemogućava otpremanje javnih ključeva servisnih naloga. Ovo pomaže u smanjenju rizika od izloženih ili ponovo korišćenih ključeva.

Sigurna konfiguracija VPC mreže

  • Definiši dozvoljene spoljne IP adrese za VM instance: Onemogućava kreiranje Compute instanci sa javnom IP adresom, što ih može izložiti internet saobraćaju.

  • Onemogući ugnježđenu virtualizaciju VM-ova: Onemogućava kreiranje ugnježđenih VM-ova na Compute Engine VM-ovima. Ovo smanjuje sigurnosni rizik od imanja nepraćenih ugnježđenih VM-ova.

  • Onemogući serijski port VM-a: Onemogućava pristup serijskom portu Compute Engine VM-ova. Ovo sprečava unos u serijski port servera korišćenjem Compute Engine API-ja.

  • Ograniči ovlašćene mreže na Cloud SQL instancama: Onemogućava javne ili ne-internetske mrežne opsege da pristupe vašim Cloud SQL bazama podataka.

  • Ograniči prosleđivanje protokola na osnovu tipa IP adrese: Onemogućava prosleđivanje VM protokola za spoljne IP adrese.

  • Ograniči pristup javnoj IP adresi na Cloud SQL instancama: Onemogućava kreiranje Cloud SQL instanci sa javnom IP adresom, što ih može izložiti internet saobraćaju.

  • Ograniči uklanjanje liena deljenog VPC projekta: Onemogućava slučajno brisanje host projekata deljenog VPC-a.

  • Postavi interni DNS setting za nove projekte na Zonal DNS Only: Onemogućava korišćenje legacy DNS postavke koja ima smanjenu dostupnost usluge.

  • Preskoči podrazumevano kreiranje mreže: Onemogućava automatsko kreiranje podrazumevane VPC mreže i povezanih resursa. Ovo izbegava preterano dozvoljena podrazumevana pravila firewall-a.

  • Onemogući korišćenje spoljnih IPv6 adresa u VPC-u: Onemogućava kreiranje spoljnih IPv6 podmreža, koje mogu biti izložene neovlašćenom internet pristupu.

IAM Uloge

Ove su slične IAM politikama u AWS-u jer svaka uloga sadrži set dozvola.

Međutim, za razliku od AWS-a, ne postoji centralizovani repozitorijum uloga. Umesto toga, resursi daju X pristupne uloge Y principima, i jedini način da saznate ko ima pristup resursu je da koristite get-iam-policy metodu nad tim resursom. Ovo može biti problem jer to znači da je jedini način da saznate koje dozvole princip ima je da pitate svaki resurs kome daje dozvole, i korisnik možda nema dozvole da dobije dozvole od svih resursa.

Postoje tri tipa uloga u IAM-u:

  • Osnovne/Primitivne uloge, koje uključuju Vlasnika, Urednika, i Pregledača uloge koje su postojale pre uvođenja IAM-a.

  • Predefinisane uloge, koje pružaju granularan pristup za određenu uslugu i upravljaju se od strane Google Cloud-a. 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 koje je korisnik odredio.

Postoji hiljade dozvola u GCP-u. Da biste proverili da li uloga ima dozvole možete pretražiti dozvolu ovde i videti koje uloge je imaju.

Takođe možete ovde pretražiti predefinisane uloge ponuđene od strane svakog proizvoda. Imajte na umu da neke uloge ne mogu biti dodeljene korisnicima već samo servisnim nalozima zbog nekih dozvola koje sadrže. Osim toga, imajte na umu da dozvole će samo imati efekta ako su dodeljene relevantnoj usluzi.

Ili proverite da li prilagođena uloga može koristiti specifičnu dozvolu ovde.

GCP - IAM, Principals & Org Policies Enum

Korisnici

U GCP konzoli nema upravljanja korisnicima ili grupama, to se radi u Google Workspace-u. Međutim, možete sinhronizovati drugog provajdera identiteta u Google Workspace-u.

Korisnici i grupe u Workspace-u se mogu pristupiti na https://admin.google.com.

MFA može biti obavezan za korisnike Workspace-a, međutim, napadač može koristiti token za pristup GCP putem CLI-a koji neće biti zaštićen MFA-om (biće zaštićen MFA-om samo kada korisnik generiše: gcloud auth login).

Grupe

Kada se organizacija kreira, preporučuje se da se kreiraju nekoliko grupa. Ako upravljate bilo kojom od njih, možete ugroziti celu ili važan deo organizacije:

Grupa

Funkcija

gcp-organization-admins (grupa ili individualni nalozi potrebni za proveru)

Upravljanje svim resursima koji pripadaju organizaciji. Dodelite ovu ulogu štedljivo; administratori organizacije imaju pristup svim vašim Google Cloud resursima. Alternativno, zbog visokih privilegija ove funkcije, razmislite o korišćenju individualnih naloga umesto kreiranja grupe.

gcp-network-admins (potrebno za proveru)

Kreiranje mreža, podmreža, pravila zaštite od požara i mrežnih uređaja poput Cloud Routera, Cloud VPN-a i cloud load balansera.

gcp-billing-admins (potrebno za proveru)

Postavljanje billing naloga i praćenje njihove upotrebe.

gcp-developers (potrebno za proveru)

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 osnove sigurnosti Google Cloud-a za više informacija o planiranju infrastrukture sigurnosti Google Cloud-a.

gcp-devops

Kreiranje ili upravljanje celokupnim tokovima rada koji podržavaju kontinuiranu integraciju i isporuku, praćenje i obezbeđivanje sistema.

gcp-logging-admins

gcp-logging-viewers

gcp-monitor-admins

gcp-billing-viewer (više nije podrazumevano)

Praćenje troškova projekata. Tipični članovi su deo finansijskog tima.

gcp-platform-viewer (više nije podrazumevano)

Pregled informacija o resursima širom organizacije Google Cloud-a.

gcp-security-reviewer (više nije podrazumevano)

Pregledavanje sigurnosti u oblaku.

gcp-network-viewer (više nije podrazumevano)

Pregled konfiguracija mreže.

grp-gcp-audit-viewer (više nije podrazumevano)

Pregledanje evidencija revizije.

gcp-scc-admin (više nije podrazumevano)

Upravljanje Security Command Centrom.

gcp-secrets-admin (više nije podrazumevano)

Upravljanje tajnama u Secret Manager-u.

Podrazumevana politika lozinki

  • Nametanje jakih lozinki

  • Između 8 i 100 karaktera

  • Bez ponovne upotrebe

  • Bez isteka

  • Ako ljudi pristupaju Workspace-u putem provajdera treće strane, ovi zahtevi se ne primenjuju.

Servisni nalozi

Ovo su principali koje resursi mogu imati priložene i pristup za lakšu interakciju sa GCP-om. Na primer, moguće je pristupiti autentifikacionom tokenu Servisnog naloga priloženog virtuelnoj mašini u metapodacima. Moguće je naići na neke sukobe prilikom korišćenja i IAM i opsega pristupa. Na primer, vaš servisni nalog može imati IAM ulogu compute.instanceAdmin ali instanca koju ste prekršili je ograničena opsegom https://www.googleapis.com/auth/compute.readonly. To bi vas sprečilo da vršite bilo kakve promene koristeći OAuth token koji je automatski dodeljen vašoj instanci.

Slično je IAM ulogama iz AWS-a. Ali za razliku od AWS-a, bilo koji servisni nalog može biti priložen bilo kom servisu (ne mora mu se dozvoliti putem politike).

Neki od servisnih naloga koje ćete pronaći zapravo su automatski generisani od strane GCP-a kada počnete koristiti uslugu, kao što su:

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

Međutim, takođe je moguće kreirati i povezati prilagođene servisne naloge sa resursima, koji će izgledati ovako:

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

Pristupni opsezi

Pristupni opsezi su dodeljeni generisanim OAuth tokenima kako bi se pristupilo GCP API endpointima. Oni ograničavaju dozvole OAuth tokena. Ovo znači da ako token pripada Vlasniku resursa ali nema u opsegu tokena pristup tom resursu, token ne može biti korišćen za zloupotrebu tih privilegija.

Google zapravo preporučuje da se pristupni opsezi ne koriste i da se potpuno oslonite na IAM. Veb menadžerski portal zapravo ovo sprovodi, ali pristupni opsezi i dalje mogu biti primenjeni na instance korišćenjem prilagođenih servisnih naloga programski.

Možete videti koje opsege su dodeljeni upitivanjem:

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"
}

Prethodni opsezi su oni generisani podrazumevano korišćenjem gcloud za pristup podacima. To je zato što kada koristite gcloud prvo kreirate OAuth token, a zatim ga koristite da kontaktirate krajnje tačke.

Najvažniji opseg od tih potencijalno je cloud-platform, što u osnovi znači da je moguće pristupiti bilo kojoj usluzi u GCP.

Možete pronaći listu svih mogućih opsega ovde.

Ako imate gcloud kredencijale pretraživača, moguće je dobiti token sa drugim opsezima, radeći nešto slično:

# 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>"

Terraform IAM politike, veze i članstva

Kako je definisano od strane terraforma u https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam korišćenjem terraforma sa GCP-om postoje različiti načini dodeljivanja pristupa principalu nad resursom:

  • Članstva: Postavljate principale kao članove uloga bez ograničenja nad ulogom ili principale. Možete postaviti korisnika kao člana uloge, a zatim postaviti grupu kao člana iste uloge i takođe postaviti te principe (korisnika i grupu) kao članove drugih uloga.

  • Veze: Više principala može biti povezano sa ulogom. Ti principali i dalje mogu biti povezani ili biti članovi drugih uloga. Međutim, ako se princip koji nije povezan sa ulogom postavi kao član povezane uloge, sledeći put kada se veza primeni, članstvo će nestati.

  • Politike: Politika je autoritativna, ona definiše uloge i principe, a zatim, ti principali ne mogu imati više uloga i te uloge ne mogu imati više principala osim ako se ta politika ne izmeni (čak ni u drugim politikama, vezama ili članstvima). Stoga, kada se uloga ili princip specificira u politici, sva njegova ovlašćenja su ograničena tom politikom. Očigledno, ovo se može zaobići u slučaju kada se principu da opcija da izmeni politiku ili dozvole za eskalaciju privilegija (kao što je kreiranje novog principala i dodeljivanje mu nove uloge).

Reference

PreviousGCP PentestingNextGCP - Federation Abuse

Last updated