Introduksjon
Orca Security har nylig identifisert en designfeil i Google Cloud Build-tjenesten, kalt «Bad.Build». Denne feilen utgjør en alvorlig sikkerhetsrisiko ettersom den lar angripere utføre Privilege Escalation, noe som gir dem uautorisert tilgang til Googles Artifact Registry sine kodelagre.
Konsekvensene av denne sårbarheten strekker seg til programvarens forsyningskjede, ettersom angripere kan utnytte den til å manipulere applikasjonsbilder med ondsinnet hensikt. Følgelig kan intetanende brukere og kunder som installerer de tuklede applikasjonene bli ofre for infeksjoner.
Denne situasjonen minner oss om den betydelige virkningen vi har sett av tidligere angrep i forsyningskjeden, som for eksempel SolarWinds, 3CXog MOVEit, og understreker de vidtrekkende konsekvensene av slike sikkerhetsbrister.
Hvordan det fungerer?
Google Cloud Bygg står som en kontinuerlig integrasjon/kontinuerlig levering (CI/CD)-tjenesten som tilbys i Google Cloud-økosystemet. Den spiller en viktig rolle i skybaserte applikasjoner ved å samhandle sømløst med andre viktige tjenester som Artefaktregisteret og App Engine.
Feilen som er nevnt skyldes et problem med for mange privilegier. Mer spesifikt, «logging.privateLoggoppføringer.listeHandlingen "tillater utilsiktet at revisjonslogger blir lagt til en utilsiktet rolle, nemlig"roller/cloudbuild.builds.builder».
Dessverre er denne standardrollen tildelt skybyggetjenestekontoen. Denne situasjonen utgjør en alvorlig risiko siden revisjonslogger inneholder sensitiv informasjon som avslører alle tillatelser knyttet til prosjektet. Denne utilsiktede tilgangen gir angripere muligheten til å utgi seg for å være skybyggekontoen, og dermed tilegne seg kunnskap om hvilke handlinger som kan utføres av forskjellige Google-kontoer. Følgelig åpner dette døren for sideveis bevegelse og rettighetseskalering, noe som representerer et ekstremt farlig sikkerhetsproblem.
Å utgi seg for å være byggetjenestekontoen krever bare cloudbuild.builds.create tillatelse, som mange forhåndsdefinerte roller har, og som gis til utviklere på enhver rimelig måte CI/CD miljø ved hjelp av Cloud Build. Så hvis du har tilgang til en slik utviklerkonto, vil det å opprette en skreddersydd byggekonfigurasjonsfil faktisk kjøre gcloud logging lesekommando, som vil liste opp tillatelsene.
Men problemet stopper ikke her: Google Cloud Build-tjenestekontoen har høye privilegier, med mange handlinger for å samhandle med Goggles artefaktregister.
Ved å utnytte sårbarheten som muliggjør etterligning av standardkontoen for Cloud Build-tjenesten, får ondsinnede aktører muligheten til å tukle med bilder lagret i Googles artefaktregister ved å injisere skadelig kode. Følgelig blir alle applikasjoner som er bygget fra disse kompromitterte bildene utsatt for potensielle konsekvenser, inkludert tjenestenektangrep (DoS), datatyveri og spredning av skadelig programvare.
Alvorlighetsgraden i situasjonen eskalerer når disse manipulerte applikasjonene er ment for distribusjon i kundenes miljøer, enten det er on-premise eller semi-SaaS. Dette utvider risikoen utover leverandørorganisasjonens infrastruktur, noe som fører til et angrep i forsyningskjeden som infiltrerer og kompromitterer kundenes miljøer. Slike angrep ligner på tidligere hendelser sett i brudd på programvare i forsyningskjeden, som for eksempel SolarWinds-bruddet. Konsekvensene av et slikt angrep kan være alvorlige, forårsake omfattende skade og påvirke flere organisasjoner i forsyningskjeden.
Det var en lignende PoC for eskalering av privilegier av Rhino sikkerhetslaboratorier, som på en annen måte utnyttet de overdrevne rettighetene til standard Cloud Build-kontoen.
Hvorfor er det farlig?
Alvorlighetsgraden av denne sårbarheten ligger i potensialet for at angripere kan utnytte artefaktregisteret og introdusere skadelig kode i artefakter. Som et resultat blir alle applikasjoner som er bygget fra disse kompromitterte bildene utsatt for ulike bivirkninger.
Disse effektene inkluderer muligheten for tjenestenektangrep, datatyveri og spredning av skadelig programvare. Dessuten, hvis disse kompromitterte applikasjonene senere distribueres. on-premise eller i et semi-SaaS-miljø, går risikoen utover offerorganisasjonen og påvirker også kundene deres. Dette scenariet ligner på forsyningskjedeangrepet som ble observert i SolarWinds-hendelsen, og fremhever de potensielle konsekvensene for både organisasjonen og kundebasen.
Xygeni-anbefaling
Anvend prinsippet om minste privilegium
- Xygeni-sensor overvåker brukerhandlinger i systemene der den er distribuert og deler dem med vår kjerneplattform, som identifiserer uvanlig oppførsel eller avvik fra normale mønstre, for eksempel uvanlige login tider eller steder, store dataoverføringer eller endringer i brukertilgangsrettigheter som er utenfor området for den «normale» brukeratferden som er modellert.
Xygenis retningslinjer og revisjon håndhever beste praksis innen tilgangskontroller, krav til flerfaktorautentisering og rollebaserte tillatelsesapplikasjoner for å begrense brukertilgang til kritiske systemer og data.
Disse verktøyene overvåker brukerhandlinger, for eksempel kodeendringer, systemtilgang eller dataoverføringer, og sammenligner dem med forhåndsdefinerte policyer og atferdsmønstre. De flagger også mistenkelige aktiviteter, som uautorisert tilgang, overdreven tilgang eller uvanlige dataoverføringsmønstre..
Hvordan sårbarheten ble håndtert
Etter å ha varslet Googles sikkerhetsteam om sårbarheten, iverksatte de tiltak ved å tilbakekalle tillatelsen logging.privateLogEntries.list fra standardkontoen for Cloud Build-tjenesten. De erkjente at selv om revisjonsloggene for setIamPolicy er relevante for revisjonsformål, var det unødvendig å gi tilgang til disse loggene fra kontoen for Cloud Build-tjenesten.
Det er imidlertid viktig å forstå at denne responsen ikke direkte adresserte rotsårbarheten i artefaktregisteret. Som et resultat forble rettighetseskaleringsvektoren og den potensielle risikoen for et angrep i forsyningskjeden upåvirket. I hovedsak begrenset Googles løsning problemet, men eliminerte det ikke helt, noe som gjorde at organisasjoner fortsatt var utsatt for betydelige risikoer i programvareforsyningskjeden.
Som svar på situasjonen rådet Google kundene sine til å endre tillatelsene til standard Cloud Build Service-kontoen ved å fjerne eventuelle rettighetsopplysninger som avviker fra prinsippet om minste privilegium (PoLP). Dette tiltaket har som mål å forbedre sikkerheten ved å sikre at kontoer bare har minimumsrettighetene som er nødvendige for å utføre de tiltenkte oppgavene.
For å forsvare seg mot dette angrepet på privilegieeskalering er det nødvendig å begrense tillatelsene som gis til Cloud Build Service-kontoen og være forsiktig med å gi cloudbuild.builds.create tillatelse til alle brukere i organisasjonen din. Viktigst av alt, må du vite at alle brukere som har fått tillatelse cloudbuild.builds.create, får også indirekte alle tillatelsene som er gitt til Cloud Build Service-kontoen. Hvis det er greit for deg, trenger du kanskje ikke bekymre deg for denne angrepsvektoren, men det anbefales fortsatt på det sterkeste å endre standardtillatelsene som er gitt til Cloud Build Service-kontoen.
Google anbefaler dette kortfattet, men gir ikke ytterligere detaljer:
«Hvis du ikke planlegger å utføre en handling som en del av byggeprosessen, anbefaler vi at du tilbakekaller den tilhørende tillatelsen fra Cloud Build-tjenestekontoen for å overholde sikkerhetsprinsippet om minste privilegium.»
Tidslinje
Rhino Security Labs publiserte et innlegg om problemet med privilegieeskalering og opprettet et PoC Python-skript * for det.
Orca Security rapporterte funnene sine til Googles sikkerhetsteam.
Google utførte en undersøkelse og implementerte en delvis løsning som svar.
Det er imidlertid viktig å merke seg at Googles løsning ikke fullstendig eliminerte den oppdagede Privilege Escalation (PE)-vektoren. I stedet begrenset den virkningen, og omdannet den effektivt til en designfeil som fortsatt utsetter organisasjoner for den bredere risikoen for et angrep i forsyningskjeden. Følgelig er ytterligere tiltak nødvendige for sikkerhetsteam for å beskytte seg mot denne vedvarende risikoen.
Konklusjon
Overdreven tilgang til standard Google Cloud Build-konto kan utnyttes av motstandere til å utføre et angrep ved å bruke en utviklerkonto som tillater opprettelse av en skybygg. Angripere kan eksfiltrere et containerbilde, tukle det med ondsinnet oppførsel og deretter sende det til artefaktregisteret, i et angrep i programvareforsyningskjeden som kan få ødeleggende konsekvenser.
Googles svar overlater arbeidet med å redusere risikoen til organisasjonene som bruker Cloud Build-tjenesten, som må tilbakekalle rettighetene for å kontrollere risikoen. Man kan be Google om ytterligere hjelp i fremtiden for å håndtere sikkerhetsproblemer med deres CI/CD system.
Referanser
- Fungerer som tiltenkt: RCE til IAM-privilegieskalering i GCP Cloud BuildRhino sikkerhetslaboratorier.
- Bad.Build: PE- og RCE-sårbarheter i Google Cloud BuildSpekkhoggersikkerhet.
- SikkerhetsbulletinGoogle Cloud.
Lær mer om Xygeni-plattformen, last ned Xygenis plattformdatablad
