Introduction
Orca Security a récemment identifié un défaut de conception dans le service Google Cloud Build, nommé « Bad.Build ». Cette faille présente un risque de sécurité sérieux car elle permet aux attaquants d'exécuter une élévation de privilèges, leur permettant ainsi une entrée non autorisée dans les référentiels de code du registre d'artefacts de Google.
Les conséquences de cette vulnérabilité s'étendent à la chaîne d'approvisionnement logicielle, car les attaquants peuvent l'exploiter pour manipuler les images d'applications dans un but malveillant. Par conséquent, les utilisateurs et clients sans méfiance qui installent les applications falsifiées peuvent être victimes d’infections.
Cette situation nous rappelle l'impact significatif observé lors d'attaques passées sur la chaîne d'approvisionnement comme SolarWinds, 3CX et DÉPLACER, soulignant les implications considérables de telles failles de sécurité.
Comment cela fonctionne?
Google Création en nuage se présente comme une intégration continue/livraison continue (CI/CD) est un service proposé au sein de l'écosystème Google Cloud. Il joue un rôle essentiel dans les applications cloud en interagissant de manière transparente avec d'autres services essentiels tels qu'Artifact Registry et App Engine.
La faille en question résulte d’un problème de privilèges excessifs. Plus précisément, le «journalisation.privateLogEntries.list" L'action permet par inadvertance de répertorier les journaux d'audit dans un rôle involontaire, à savoir "rôles/cloudbuild.builds.builder. »
Malheureusement, ce rôle par défaut est attribué au compte du service de build cloud. Cette situation présente un risque grave puisque les journaux d'audit contiennent des informations sensibles, révélant toutes les autorisations associées au projet. Cet accès involontaire donne aux attaquants la possibilité d'usurper l'identité du compte de build cloud, acquérant ainsi des connaissances sur les actions qui peuvent être effectuées par différents comptes Google. Par conséquent, cela ouvre la porte à des mouvements latéraux et à une élévation des privilèges, présentant une vulnérabilité de sécurité extrêmement dangereuse.
L'usurpation d'identité du compte de service de build nécessite uniquement le cloudbuild.builds.créer autorisation, dont disposent de nombreux rôles prédéfinis, et qui sont accordées aux développeurs dans toute mesure raisonnable CI/CD environnement utilisant Cloud Build. Ainsi, si vous avez accès à un compte développeur de ce type, la création d'un fichier de configuration de build personnalisé exécutera l'application. commande de lecture de journalisation gcloud, qui listera les autorisations.
Mais le problème ne s'arrête pas là : le Le compte de service Google Cloud Build est hautement privilégié, avec de nombreuses actions pour interagir avec le registre d'artefacts de Goggle.
En exploitant la vulnérabilité qui permet l'usurpation d'identité du compte de service Cloud Build par défaut, les acteurs malveillants ont la possibilité de falsifier les images stockées dans le registre d'artefacts de Google en injectant du code malveillant. Par conséquent, toute application créée à partir de ces images compromises devient susceptible de subir des conséquences potentielles, notamment des attaques par déni de service (DoS), le vol de données et la propagation de logiciels malveillants.
La gravité de la situation s'aggrave lorsque ces applications manipulées sont destinées à être déployées dans les environnements des clients, que ce soit on-premise ou semi-SaaS. Cela étend le risque au-delà de l'infrastructure du fournisseur, ce qui conduit à une attaque de la chaîne d'approvisionnement qui s'infiltre et compromet l'environnement des clients. De telles attaques sont similaires aux incidents précédents observés lors de violations de la chaîne d'approvisionnement logicielle, comme celle de SolarWinds. Les conséquences d'une telle attaque peuvent être graves, causant des dommages étendus et affectant plusieurs organisations de la chaîne d'approvisionnement.
Il y a eu une élévation de privilèges similaire PoC par Laboratoires de sécurité de Rhino, qui exploitait de manière différente les privilèges excessifs du compte Cloud Build par défaut.
Pourquoi est-ce dangereux ?
La gravité de cette vulnérabilité réside dans la possibilité pour les attaquants d'exploiter Artifact Registry et d'introduire du code malveillant dans les artefacts. En conséquence, toutes les applications créées à partir de ces images compromises deviennent sensibles à divers effets indésirables.
Ces effets incluent la possibilité d'attaques par déni de service, de vols de données et de propagation de logiciels malveillants. De plus, si ces applications compromises sont ensuite déployées, on-premise Dans un environnement semi-SaaS, le risque s'étend au-delà de l'organisation victime et impacte également ses clients. Ce scénario ressemble à l'attaque de la chaîne d'approvisionnement observée lors de l'incident de SolarWinds, soulignant les conséquences potentielles pour l'organisation et sa clientèle.
-
Recommandation Xygeni
Appliquer le principe du moindre privilège
- Capteur Xygeni surveille les actions des utilisateurs dans les systèmes où il est déployé et les partage avec notre plateforme principale, qui identifie les comportements inhabituels ou les écarts par rapport aux modèles normaux, tels que les comportements inhabituels. login des heures ou des lieux, des transferts de données volumineux ou des modifications des droits d'accès des utilisateurs qui sont hors de portée du comportement « normal » des utilisateurs modélisé.
Les politiques et l'audit de Xygeni appliquent les meilleures pratiques en matière de contrôles d'accès, d'exigences d'authentification multifacteur et d'applications d'autorisations basées sur les rôles pour limiter l'accès des utilisateurs aux systèmes et données critiques.
Ces outils surveillent les actions des utilisateurs, telles que les modifications de code, l'accès au système ou les transferts de données, et les comparent à des politiques et des modèles de comportement prédéfinis. Ils signalent également les activités suspectes, telles qu'un accès non autorisé, des privilèges excessifs ou des modèles de transfert de données inhabituels..
Comment la vulnérabilité a été gérée
Après avoir informé l'équipe de sécurité de Google de la vulnérabilité, elle a pris des mesures en révoquant l'autorisation logging.privateLogEntries.list du compte de service Cloud Build par défaut. Ils ont reconnu que même si les journaux d'audit setIamPolicy sont pertinents à des fins d'audit, il n'était pas nécessaire d'accorder l'accès à ces journaux du point de vue du compte de service de build cloud.
Cependant, il est crucial de comprendre que cette réponse ne traite pas directement la vulnérabilité racine au sein d'Artifact Registry. En conséquence, le vecteur d’élévation des privilèges et le risque potentiel d’attaque de la chaîne d’approvisionnement ne sont pas affectés. Essentiellement, le correctif de Google a limité le problème mais ne l'a pas entièrement éliminé, laissant les organisations toujours exposées à des risques importants liés à la chaîne d'approvisionnement en logiciels.
En réponse à cette situation, Google a conseillé à ses clients de modifier les autorisations du compte de service Cloud Build par défaut en supprimant toutes les informations d'identification qui s'écartaient du principe du moindre privilège (PoLP). Cette mesure vise à renforcer la sécurité en garantissant que les comptes ne disposent que des privilèges minimaux nécessaires pour effectuer les tâches prévues.
Pour se défendre contre cette attaque par élévation de privilèges, il est nécessaire de restreindre les autorisations accordées au compte de service Cloud Build et d'être prudent en accordant le cloudbuild.builds.créer autorisation à tous les utilisateurs de votre organisation. Plus important encore, vous devez savoir que tout utilisateur bénéficiant d'un accès cloudbuild.builds.créer, reçoit également indirectement toutes les autorisations accordées au compte de service Cloud Build. Si cela vous convient, vous n'aurez peut-être pas à vous soucier de ce vecteur d'attaque, mais il est toujours fortement recommandé de modifier les autorisations par défaut accordées au compte de service Cloud Build.
Google le recommande succinctement, mais ne fournit pas plus de détails :
"Si vous ne prévoyez pas d'effectuer une action dans le cadre du processus de génération, nous vous recommandons de révoquer l'autorisation correspondante du compte de service Cloud Build pour respecter le principe de sécurité du moindre privilège."
Forum
Cependant, il est essentiel de noter que la solution proposée par Google n'a pas entièrement éliminé le vecteur d'escalade de privilèges (PE) découvert. Au lieu de cela, il a limité son impact, le transformant en un défaut de conception qui expose toujours les organisations au risque plus large d’une attaque sur la chaîne d’approvisionnement. Par conséquent, des mesures supplémentaires sont nécessaires pour que les équipes de sécurité se prémunissent contre ce risque persistant.
Conclusion
Les privilèges excessifs accordés au compte Google Cloud Build par défaut pourraient être exploités par des adversaires pour lancer une attaque en utilisant un compte de développeur permettant de créer une version cloud. Les attaquants peuvent exfiltrer une image de conteneur, la falsifier avec un comportement malveillant, puis la transférer vers Artifact Registry, dans le cadre d'une attaque de la chaîne d'approvisionnement logicielle qui peut avoir des conséquences dévastatrices.
La réponse de Google laisse la tâche d'atténuation aux organisations utilisant le service Cloud Build, qui doivent révoquer les privilèges pour contrôler le risque. Google pourrait être amené à fournir une assistance supplémentaire à l'avenir pour gérer les problèmes de sécurité liés à leurs services. CI/CD système.
Références
- Fonctionnement comme prévu : élévation des privilèges RCE vers IAM dans GCP Cloud Build. Laboratoires de sécurité Rhino.
- Bad.Build : vulnérabilités PE et RCE dans Google Cloud Build. Sécurité des orques.
- Bulletin de sécurité. Google Cloud.
En savoir plus sur la plateforme Xygeni, téléchargez la fiche technique de la plateforme Xygeni
