introducció
Orca Security ha identificat recentment una falla de disseny al servei Google Cloud Build, anomenada "Bad.Build". Aquesta falla representa un risc de seguretat greu, ja que permet als atacants executar l'escalada de privilegis, atorgant-los accés no autoritzat als repositoris de codi del registre d'artefactes de Google.
Les conseqüències d'aquesta vulnerabilitat s'estenen a la cadena de subministrament de programari, ja que els atacants poden explotar-la per manipular imatges d'aplicacions amb intencions malicioses. En conseqüència, els usuaris i clients desprevinguts que instal·lin les aplicacions manipulades poden ser víctimes d'infeccions.
Aquesta situació ens recorda l'impacte significatiu que es va observar en atacs anteriors a la cadena de subministrament com ara SolarWinds. 3CXi Moure, posant èmfasi en les implicacions de gran abast d'aquestes lacunes de seguretat.
Com funciona?
Google Construcció al núvol es presenta com una integració contínua/lliurament continu (CI/CD) servei que s'ofereix dins l'ecosistema de Google Cloud. Té un paper vital en les aplicacions basades en el núvol, ja que interactua perfectament amb altres serveis essencials com ara l'Artifact Registry i l'App Engine.
El defecte en qüestió és el resultat d'un problema amb privilegis excessius. En concret, el "logging.privateLogEntries.list"L'acció permet inadvertidament la llista de registres d'auditoria per a una funció no prevista, és a dir, "roles/cloudbuild.builds.builder".
Malauradament, aquest rol per defecte està assignat al compte del servei de compilació al núvol. Aquesta situació representa un risc greu, ja que els registres d'auditoria contenen informació confidencial que revela tots els permisos associats al projecte. Aquest accés no intencionat atorga als atacants la capacitat de suplantar el compte de compilació al núvol, adquirint així coneixement sobre quines accions poden realitzar diferents comptes de Google. En conseqüència, això obre la porta al moviment lateral i a l'escalada de privilegis, presentant una vulnerabilitat de seguretat extremadament perillosa.
Per suplantar la identitat del compte del servei de compilació només cal cloudbuild.builds.create permisos, que tenen molts rols predefinits i que es concedeixen als desenvolupadors en qualsevol moment raonable CI/CD entorn mitjançant Cloud Build. Per tant, si teniu accés a un d'aquests comptes de desenvolupador, la creació d'un fitxer de configuració de compilació personalitzat executarà realment el Ordre de lectura de registre de gcloud, que enumerarà els permisos.
Però el problema no s'atura aquí: la El compte de servei de Google Cloud Build té privilegis elevats, amb moltes accions per interactuar amb el Registre d'Artefactes de Goggle.
Aprofitant la vulnerabilitat que permet la suplantació del compte de servei predeterminat de Cloud Build, els actors maliciosos aconsegueixen manipular imatges emmagatzemades al Registre d'Artefactes de Google injectant codi maliciós. En conseqüència, qualsevol aplicació creada a partir d'aquestes imatges compromeses esdevé susceptible a possibles conseqüències, com ara atacs de denegació de servei (DoS), robatori de dades i propagació de programari maliciós.
La gravetat de la situació augmenta quan aquestes aplicacions manipulades estan destinades a ser implementades en entorns de clients, ja sigui on-premise o semi-SaaS. Això amplia el risc més enllà de la infraestructura de l'organització proveïdora, donant lloc a un atac a la cadena de subministrament que s'infiltra i compromet els entorns dels clients. Aquests atacs són similars a incidents anteriors observats en violacions de la cadena de subministrament de programari, com ara la violació de SolarWinds. Les implicacions d'un atac d'aquest tipus poden ser greus, causant danys generalitzats i afectant múltiples organitzacions dins de la cadena de subministrament.
Hi va haver una prova de concepte d'escalada de privilegis similar per part de Laboratoris de seguretat Rhino, que explotava de manera diferent els privilegis excessius del compte predeterminat de Cloud Build.
Per què és perillós?
La gravetat d'aquesta vulnerabilitat rau en el seu potencial perquè els atacants explotin el Registre d'Artefactes i introdueixin codi maliciós als artefactes. Com a resultat, qualsevol aplicació creada a partir d'aquestes imatges compromeses esdevé susceptible a diversos efectes adversos.
Aquests efectes inclouen la possibilitat d'atacs de denegació de servei, robatori de dades i propagació de programari maliciós. A més, si aquestes aplicacions compromeses es despleguen posteriorment on-premise o en un entorn semi-SaaS, el risc s'estén més enllà de l'organització víctima i afecta també els seus clients. Aquest escenari s'assembla a l'atac a la cadena de subministrament que es va presenciar en l'incident de SolarWinds, i destaca les possibles conseqüències tant per a l'organització com per a la seva base de clients.
Recomanació de Xygeni
Aplicar el principi del mínim privilegi
- Sensor de xigen supervisa les accions dels usuaris als sistemes on s'implementa i les comparteix amb la nostra plataforma principal, que identifica comportaments inusuals o desviacions dels patrons normals, com ara comportaments inusuals login horaris o ubicacions, grans transferències de dades o canvis en els drets d'accés dels usuaris que estan fora del rang del comportament "normal" de l'usuari modelat.
Les polítiques i l'auditoria de Xygeni apliquen les millors pràctiques en controls d'accés, requisits d'autenticació multifactor i aplicacions de permisos basades en rols per limitar l'accés dels usuaris a sistemes i dades crítiques.
Aquestes eines supervisen les accions dels usuaris, com ara canvis de codi, accés al sistema o transferències de dades, i les comparen amb polítiques i patrons de comportament predefinits. També marquen activitats sospitoses, com ara accés no autoritzat, privilegis excessius o patrons de transferència de dades inusuals..
Com es va gestionar la vulnerabilitat
Després de notificar la vulnerabilitat a l'equip de seguretat de Google, van prendre mesures revocant el permís logging.privateLogEntries.list del compte de servei predeterminat de Cloud Build. Van reconèixer que, si bé els registres d'auditoria setIamPolicy són rellevants per a finalitats d'auditoria, no era necessari concedir accés a aquests registres des de la perspectiva del compte de servei de compilació de núvol.
Tanmateix, és crucial entendre que aquesta resposta no va abordar directament la vulnerabilitat arrel dins del Registre d'Artefactes. Com a resultat, el vector d'escalada de privilegis i el risc potencial d'un atac a la cadena de subministrament no es van veure afectats. Essencialment, la solució de Google va limitar el problema però no el va eliminar del tot, deixant les organitzacions encara exposades a riscos importants de la cadena de subministrament de programari.
En resposta a la situació, Google va aconsellar als seus clients que modifiquessin els permisos del compte de servei de Cloud Build per defecte eliminant qualsevol credencial de dret que es desviés del principi de privilegi mínim (PoLP). Aquesta mesura té com a objectiu millorar la seguretat garantint que els comptes només tinguin els privilegis mínims necessaris per dur a terme les tasques previstes.
Per defensar-se contra aquest atac d'escalada de privilegis, cal restringir els permisos atorgats al compte de servei de Cloud Build i anar amb compte en atorgar-los. cloudbuild.builds.create permís a qualsevol usuari de la vostra organització. El més important és que heu de saber que qualsevol usuari a qui se li concedeixi cloudbuild.builds.create, també rep indirectament tots els permisos concedits al compte de servei Cloud Build. Si això us sembla bé, potser no us haureu de preocupar per aquest vector d'atac, però encara és molt recomanable modificar els permisos predeterminats concedits al compte de servei Cloud Build.
Google recomana això succintament, però no proporciona més detalls:
"Si no teniu previst dur a terme una acció com a part del procés de compilació, us recomanem que revoqueu el permís corresponent del compte de servei Cloud Build per complir amb el principi de seguretat de privilegi mínim."
Línia de temps
Rhino Security Labs ha publicat una publicació sobre el problema d'escalada de privilegis i ha creat un script de Python per a la prova de concepte.
Orca Security va informar de les seves troballes a l'equip de seguretat de Google.
Google va dur a terme una investigació i va implementar una solució parcial en resposta.
Tanmateix, és essencial tenir en compte que el remei de Google no va eliminar completament el vector d'escalada de privilegis (PE) descobert. En canvi, va restringir el seu impacte, transformant-lo efectivament en un defecte de disseny que encara exposa les organitzacions al risc més ampli d'un atac a la cadena de subministrament. En conseqüència, calen mesures addicionals perquè els equips de seguretat es protegeixin contra aquest risc persistent.
Conclusió
Els adversaris podrien aprofitar els privilegis excessius atorgats al compte predeterminat de Google Cloud Build per muntar un atac mitjançant un compte de desenvolupador que permeti crear una compilació al núvol. Els atacants poden exfiltrar una imatge de contenidor, manipular-la amb comportaments maliciosos i després enviar-la al Registre d'Artefactes, en un atac de la cadena de subministrament de programari que pot tenir conseqüències devastadores.
La resposta de Google deixa la feina de mitigació a les organitzacions que utilitzen el servei Cloud Build, que han de revocar els privilegis per controlar el risc. Es pot demanar a Google que proporcioni ajuda addicional en el futur per gestionar els problemes de seguretat amb els seus CI/CD sistema.
referències
- Funcionant segons el previst: escalada de privilegis de RCE a IAM a GCP Cloud BuildLaboratoris de seguretat Rhino.
- Bad.Build: Vulnerabilitats de PE i RCE a Google Cloud BuildSeguretat Orca.
- Butlletí de SeguretatGoogle Cloud.
Més informació sobre la plataforma Xygeni, descarregueu la fitxa tècnica de la plataforma Xygeni
