Résumé
- Le rapport d'incident public de CircleCI indique qu'un tiers non autorisé a utilisé un logiciel malveillant sur l'ordinateur portable d'un ingénieur de CircleCI pour voler une session SSO valide avec 2FA, étendre l'accès à un sous-ensemble de systèmes de production et exfiltrer des informations clients, dont des variables d'environnement, des jetons et des clés.
- Qui avait le contrôle pratique sur la garde des secrets clients, la résistance à la compromission des appareils des employés, la révocation des jetons, l'exposition des variables d'environnement, la notification des clients, les conseils de rotation et la preuve que la limite de confiance CI est devenue plus résiliente?
- Le problème de responsabilité est que les plateformes CI détiennent une autorité opérationnelle sur les identifiants de déploiement même lorsque le code d'application sous-jacent, les comptes cloud et les systèmes métier appartiennent aux clients.
- Les développeurs, les équipes plateforme, les entreprises, les utilisateurs en aval, les équipes de sécurité, les auditeurs et les propriétaires de ressources cloud avaient besoin de preuves que la rotation des secrets clients était complète et que la réexposition était limitée.
- Cet article considère le rapport d'incident, l'alerte de sécurité, les conseils de support et la documentation produit de CircleCI comme le dossier public principal. GitHub, AWS, Google Cloud, CISA, NIST et d'autres documents techniques sont utilisés pour évaluer la conception des contrôles, non pour affirmer que ces organisations ont émis des conclusions spécifiques contre CircleCI.
Pourquoi ce cas figure dans un dossier de risque et de responsabilité
L'incident de CircleCI de janvier 2023 figure dans un dossier de risque et de responsabilité car l'intégration continue n'est plus une commodité de développement périphérique. Les systèmes CI se situent souvent entre le code source, les registres de paquets, les comptes cloud, les systèmes de déploiement, les outils de signature, les environnements de test, l'infrastructure de staging et les chemins de publication en production.
Une plateforme qui exécute des builds peut également détenir les identifiants qui permettent à ces builds de récupérer des dépendances privées, de pousser des images conteneur, de déployer l'infrastructure, de publier des paquets, d'assumer des rôles cloud ou de se connecter à des services internes. Lorsqu'un fournisseur CI dit à chaque client de faire pivoter les secrets, l'incident est déjà passé de la sécurité du fournisseur au risque opérationnel du client.
Le dossier public commence avec l'alerte de sécurité de CircleCI àhttps://circleci.com/blog/january-4-2023-security-alert/et son rapport d'incident ultérieur àhttps://circleci.com/blog/jan-4-2023-incident-report/. CircleCI a indiqué avoir alerté les clients le 4 janvier 2023 et recommandé de faire pivoter tous les secrets stockés dans CircleCI. Son rapport d'incident indique que l'attaquant a exploité un logiciel malveillant déployé sur l'ordinateur portable d'un ingénieur de CircleCI, a volé une session SSO valide avec 2FA, a usurpé l'identité de l'employé, a étendu l'accès à un sous-ensemble de systèmes de production et a exfiltré des informations clients le 22 décembre 2022. Selon CircleCI, ces données comprenaient des variables d'environnement, des jetons et des clés pour des systèmes tiers.
Cette formulation rend le problème de responsabilité spécifique. La préoccupation n'était pas simplement qu'un poste de travail d'employé d'un fournisseur ait été compromis. La préoccupation était qu'un chemin compromis d'employé puisse atteindre des secrets clients utiles en dehors de CircleCI. Ces secrets pouvaient appartenir à des fournisseurs cloud, des systèmes de contrôle de version, des registres de paquets, des cibles de déploiement, des runners auto-hébergés, des API, des magasins de données ou des systèmes métier internes.
CircleCI pouvait révoquer certains jetons émis par la plateforme et faire pivoter certaines intégrations avec des partenaires, mais ne pouvait pas unilatéralement faire pivoter tous les identifiants cloud, secrets d'application, clés SSH, clés de déploiement, jetons de registre ou clés API spécifiques à un service de chaque client. Cela a forcé les clients à entreprendre un exercice de correction vaste et distribué.
Le cas illustre également l'économie des outils de développement. Les produits CI sont adoptés car ils réduisent les coûts de coordination, normalisent les workflows de build et permettent aux équipes de livrer plus rapidement. La même logique économique concentre la garde des secrets. Au lieu que chaque équipe construise un système de déploiement isolé, les équipes placent les identifiants à l'intérieur d'un plan de contrôle CI partagé et font confiance au fournisseur pour injecter ces identifiants au bon moment. C'est efficace jusqu'à ce que le modèle d'accès interne du fournisseur échoue.
Ensuite, l'efficacité devient un rayon de souffrance partagé: de nombreux clients doivent interrompre le travail d'ingénierie pour trouver, faire pivoter et valider les identifiants intégrés dans les workflows CI.
Une analyse de responsabilité faible blâmerait l'ordinateur portable infecté d'un employé et s'arrêterait là. Le propre rapport de CircleCI a rejeté ce cadre étroit, affirmant qu'un incident de sécurité est un échec systémique et que la responsabilité de l'organisation est de construire des garde-fous contre tous les vecteurs d'attaque. Ce principe est central. L'attaquant était responsable de l'intrusion.
CircleCI contrôlait les protections des postes de travail des employés, la conception de l'accès à la production, la confiance des sessions, le stockage des secrets clients, la révocation des jetons, la divulgation des incidents et les outils de correction. Les clients contrôlaient les systèmes en aval dont les identifiants étaient stockés dans CircleCI. GitHub, Bitbucket, GitLab, AWS, Google Cloud et d'autres fournisseurs contrôlaient des systèmes de jetons et d'audit séparés. L'incident exigeait une coordination entre tous.
L'incident a transformé les secrets clients en une obligation de réparation partagée
Le rapport d'incident de CircleCI est étonnamment direct concernant le côté client de l'exposition. Il indique que si les clients ont stocké des secrets sur la plateforme pendant la période concernée, ils doivent supposer que ces secrets ont été consultés et doivent prendre les mesures d'atténuation recommandées. Il indique également que les clients doivent rechercher une activité suspecte dans leurs systèmes à partir du 16 décembre 2022 jusqu'à la date à laquelle ils ont terminé la rotation des secrets après la divulgation du 4 janvier.
C'est une frontière publique forte: CircleCI n'a pas simplement dit qu'il y avait une possibilité d'exposition; il a dit aux clients de traiter les secrets stockés comme exposés à des fins de correction.
La différence est importante. Un secret CI n'est pas comme un mot de passe utilisé uniquement pour se connecter au fournisseur CI. Il peut s'agir d'un identifiant fonctionnel pour un autre système. Une variable d'environnement de projet peut contenir une URL de base de données, une clé d'accès cloud, un jeton de paquet privé, un secret de signature webhook, une variable Terraform, un identifiant de déploiement ou une clé API. Une variable de contexte peut être partagée entre de nombreux projets. Un jeton de runner peut connecter une capacité d'exécution auto-hébergée à la plateforme.
Un jeton OAuth peut connecter CircleCI à des fournisseurs de contrôle de version. Les clés SSH peuvent donner accès à un dépôt ou à un serveur. Lorsque ces secrets sont exposés, le risque en aval est distribué sur tous les systèmes qui les ont acceptés.
La propre documentation de CircleCI aide à expliquer pourquoi. Le guide des variables d'environnement àhttps://circleci.com/docs/guides/security/env-vars/décrit les variables d'environnement comme un moyen de configurer les jobs et de stocker les secrets, clés privées et contextes. La documentation des contextes àhttps://circleci.com/docs/guides/security/contexts/décrit les variables d'environnement au niveau de l'organisation qui peuvent être injectées au moment de l'exécution dans les jobs. L'article de support pour l'incident du 4 janvier àhttps://support.circleci.com/hc/en-us/articles/11816211460891-Rotating-Secrets-for-January-4th-Incidenténumère les catégories pratiques de rotation: jetons OAuth, jetons API de projet, variables d'environnement de projet, variables de contexte, jetons API utilisateur, clés SSH de projet et jetons de runner. Cette liste montre le véritable objet de la gouvernance. Un client n'avait pas besoin de demander si un seul mot de passe était exposé; il devait inventorier le graphe de confiance CI.
Le graphe de confiance avait plusieurs couches de propriété. CircleCI pouvait révoquer les jetons API de projet et personnel créés avant une date limite spécifiée. Il pouvait travailler avec GitHub et Atlassian pour faire pivoter les jetons OAuth au nom des clients. Il pouvait publier des conseils et des outils pour identifier les secrets stockés. Mais une clé d'accès AWS, un mot de passe de base de données, une clé de signature, un jeton Kubernetes ou une clé API SaaS tierce d'un client devait être pivoté dans le système qui honore réellement cette clé.
CircleCI ne pouvait pas voir toute l'utilisation en aval, et les clients ne pouvaient pas voir toute la forensique interne de CircleCI. La réparation était donc conjointe: CircleCI devait divulguer assez rapidement et fournir suffisamment de détails; les clients devaient effectuer leur propre rotation et examen des journaux.
C'est pourquoi le cas n'est pas réductible à une violation de fournisseur privé. Le rapport d'incident de CircleCI indique que moins de cinq clients avaient informé CircleCI d'un accès non autorisé à des systèmes tiers à la suite de l'incident au moment de la publication. C'est une limite importante et ne doit pas être gonflée en affirmations non étayées selon lesquelles tous les systèmes clients ont été violés. En même temps, CircleCI a également déclaré qu'il ne pouvait pas savoir si les clés et jetons exfiltrés avaient été utilisés contre les systèmes tiers de chaque client.
Cette incertitude est exactement la raison pour laquelle la rotation des secrets est devenue le test de responsabilité.
... (suite de la traduction)