Introduzione
Orca Security ha recentemente identificato un difetto di progettazione nel servizio Google Cloud Build, denominato "Bad.Build". Questa falla rappresenta un serio rischio per la sicurezza poiché consente agli aggressori di eseguire l'escalation dei privilegi, garantendo loro l'accesso non autorizzato ai repository di codici di Artifact Registry di Google.
Le conseguenze di questa vulnerabilità si estendono alla catena di fornitura del software, poiché gli aggressori possono sfruttarla per manipolare le immagini delle applicazioni con intenti dannosi. Di conseguenza, utenti e clienti ignari che installano applicazioni manomesse potrebbero cadere vittime di infezioni.
Questa situazione ci ricorda l’impatto significativo testimoniato negli attacchi passati alla catena di fornitura come SolarWinds, 3CXe MUOVITI, sottolineando le implicazioni di vasta portata di tali carenze in materia di sicurezza.
Come funziona?
Google Costruzione cloud si configura come un'integrazione continua/consegna continua (CI/CD) servizio offerto all'interno dell'ecosistema Google Cloud. Svolge un ruolo fondamentale nelle applicazioni basate su cloud interagendo in modo fluido con altri servizi essenziali come Artifact Registry e App Engine.
Il difetto in questione deriva da un problema con privilegi eccessivi. Nello specifico, il “logging.privateLogEntries.list" L'azione consente inavvertitamente di elencare i log di controllo in un ruolo non previsto, vale a dire "ruoli/cloudbuild.builds.builder. "
Purtroppo, questo ruolo predefinito è assegnato all'account del servizio di creazione cloud. Questa situazione rappresenta un grave rischio poiché i registri di controllo contengono informazioni sensibili, rivelando tutte le autorizzazioni associate al progetto. Questo accesso involontario garantisce agli aggressori la possibilità di impersonare l'account di creazione del cloud, acquisendo così informazioni su quali azioni possono essere eseguite da diversi Account Google. Di conseguenza, ciò apre la porta a movimenti laterali e all’escalation dei privilegi, presentando una vulnerabilità della sicurezza estremamente pericolosa.
La rappresentazione dell'account del servizio di compilazione richiede solo il file cloudbuild.builds.create autorizzazione, che molti ruoli predefiniti hanno e che viene concessa agli sviluppatori in qualsiasi modo ragionevole CI/CD ambiente che utilizza Cloud Build. Quindi, se hai accesso all'account di uno di questi sviluppatori, la creazione di un file di configurazione di build personalizzato eseguirà effettivamente il Comando di lettura della registrazione gcloud, che elencherà le autorizzazioni.
Ma il problema non si ferma qui: il L'account del servizio Google Cloud Build ha privilegi elevati, con molte azioni per interagire con il registro degli artefatti di Goggle.
Sfruttando la vulnerabilità che consente la rappresentazione dell'account del servizio Cloud Build predefinito, gli autori malintenzionati ottengono la capacità di manomettere le immagini archiviate nell'Artifact Registry di Google iniettando codice dannoso. Di conseguenza, qualsiasi applicazione creata a partire da queste immagini compromesse diventa esposta a potenziali conseguenze, tra cui attacchi Denial-of-Service (DoS), furto di dati e diffusione di malware.
La gravità della situazione aumenta quando queste applicazioni manipolate sono destinate all'implementazione negli ambienti dei clienti, sia on-premise o semi-SaaS. Ciò espande il rischio oltre l'infrastruttura dell'organizzazione fornitrice, portando a un attacco alla supply chain che si infiltra e compromette gli ambienti dei clienti. Tali attacchi sono simili a precedenti incidenti osservati nelle violazioni della supply chain del software, come la violazione di SolarWinds. Le implicazioni di un tale attacco possono essere gravi, causando danni diffusi e colpendo più organizzazioni all'interno della supply chain
C'è stato un PoC di escalation dei privilegi simile Laboratori di sicurezza di Rhino, che sfruttava in modo diverso gli eccessivi privilegi dell'account Cloud Build predefinito.
Perché è pericoloso?
La gravità di questa vulnerabilità risiede nella possibilità che gli aggressori sfruttino l'Artifact Registry e introducano codice dannoso negli artefatti. Di conseguenza, qualsiasi applicazione creata a partire da queste immagini compromesse diventa suscettibile a vari effetti negativi.
Questi effetti includono la possibilità di attacchi Denial-of-Service, furto di dati e propagazione di malware. Inoltre, se queste applicazioni compromesse vengono successivamente distribuite on-premise o in un ambiente semi-SaaS, il rischio si estende oltre l'organizzazione vittima per avere un impatto anche sui suoi clienti. Questo scenario assomiglia all'attacco alla supply chain osservato nell'incidente SolarWinds, evidenziando le potenziali conseguenze sia per l'organizzazione che per la sua base di clienti.
-
Raccomandazione di Xygeni
Applicare il principio del privilegio minimo
- Sensore Xygeni monitora le azioni degli utenti nei sistemi in cui è distribuito e le condivide con la nostra piattaforma principale, che identifica comportamenti insoliti o deviazioni dai modelli normali, come insoliti login orari o luoghi, trasferimenti di dati di grandi dimensioni o modifiche dei diritti di accesso degli utenti che esulano dall'intervallo del comportamento "normale" dell'utente modellato.
Le politiche e gli audit di Xygeni applicano le migliori pratiche nei controlli di accesso, nei requisiti di autenticazione a più fattori e nelle applicazioni di autorizzazioni basate sui ruoli per limitare l'accesso degli utenti a sistemi e dati critici.
Questi strumenti monitorano le azioni degli utenti, come modifiche al codice, accesso al sistema o trasferimenti di dati, e le confrontano con policy e modelli comportamentali predefiniti. Segnalano inoltre attività sospette, come accessi non autorizzati, privilegi eccessivi o modelli insoliti di trasferimento dei dati.
Come è stata gestita la vulnerabilità
Dopo aver notificato la vulnerabilità al team di sicurezza di Google, è intervenuto revocando l'autorizzazione logging.privateLogEntries.list dall'account del servizio Cloud Build predefinito. Hanno riconosciuto che, sebbene i log di controllo setIamPolicy siano rilevanti ai fini del controllo, concedere l'accesso a questi log dal punto di vista dell'account del servizio di creazione cloud non era necessario.
Tuttavia, è fondamentale comprendere che questa risposta non ha risolto direttamente la vulnerabilità root all'interno dell'Artifact Registry. Di conseguenza, il vettore dell’escalation dei privilegi e il potenziale rischio di un attacco alla catena di fornitura sono rimasti inalterati. In sostanza, la soluzione di Google ha limitato il problema ma non lo ha eliminato del tutto, lasciando le organizzazioni ancora esposte a rischi significativi nella catena di fornitura del software.
In risposta alla situazione, Google ha consigliato ai propri clienti di modificare le autorizzazioni dell'account del servizio Cloud Build predefinito rimuovendo eventuali credenziali di autorizzazione che si discostavano dal principio del privilegio minimo (PoLP). Questa misura mira a migliorare la sicurezza garantendo che gli account dispongano solo dei privilegi minimi necessari per svolgere le attività previste.
Per difendersi da questo attacco di escalation di privilegi, è necessario limitare le autorizzazioni concesse all'account del servizio Cloud Build e prestare attenzione nel concedere i cloudbuild.builds.create autorizzazione a tutti gli utenti della tua organizzazione. Ancora più importante, è necessario sapere che qualsiasi utente a cui viene concesso cloudbuild.builds.create, vengono inoltre concessi indirettamente tutti i permessi concessi all'Account del Servizio Cloud Build. Se per te va bene, potresti non doverti preoccupare di questo vettore di attacco, ma è comunque altamente consigliabile modificare le autorizzazioni predefinite concesse all'account del servizio Cloud Build.
Google lo raccomanda in modo succinto, ma non fornisce ulteriori dettagli:
"Se non prevedi di eseguire un'azione come parte del processo di creazione, ti consigliamo di revocare l'autorizzazione corrispondente dall'account del servizio Cloud Build per rispettare il principio di sicurezza del privilegio minimo."
timeline
Tuttavia, è essenziale notare che la soluzione adottata da Google non ha eliminato del tutto il vettore Privilege Escalation (PE) scoperto. Al contrario, ne ha limitato l’impatto, trasformandolo di fatto in un difetto di progettazione che espone ancora le organizzazioni al rischio più ampio di un attacco alla catena di fornitura. Di conseguenza, sono necessarie misure aggiuntive per i team di sicurezza per salvaguardarsi da questo rischio persistente.
Conclusione
Privilegi eccessivi concessi all'account Google Cloud Build predefinito potrebbero essere sfruttati dagli avversari per sferrare un attacco utilizzando un account sviluppatore che consente di creare una build cloud. Gli aggressori possono esfiltrare un'immagine del contenitore, manometterla con comportamenti dannosi e quindi inserirla nell'Artifact Registry, in un attacco alla catena di fornitura del software che potrebbe avere conseguenze devastanti.
La risposta di Google lascia il lavoro di mitigazione alle organizzazioni che utilizzano il servizio Cloud Build, che devono revocare i privilegi per controllare il rischio. Si può chiedere a Google di fornire ulteriore assistenza in futuro per gestire i problemi di sicurezza con i propri CI/CD .
Referenze
- Funzionamento come previsto: escalation dei privilegi da RCE a IAM in GCP Cloud Build. Laboratori di sicurezza di Rhino.
- Bad.Build: vulnerabilità PE e RCE in Google Cloud Build. Sicurezza dell'Orca.
- Security Bulletin. GoogleNuvola.
Scopri di più sulla piattaforma Xygeni, scarica la scheda tecnica della piattaforma Xygeni
