- Cloudflare a annoncé avoir détecté, le 23 novembre 2023, un acteur de menace sur ses serveurs Atlassian auto-hébergés, tout en précisant que les données clients, les systèmes clients ainsi que les systèmes et configurations du réseau mondial n’avaient pas été affectés
- Le vecteur d’intrusion reposait sur 1 jeton d’accès et 3 identifiants de comptes de service non renouvelés après la compromission d’Okta d’octobre 2023, l’accès se concentrant sur l’environnement Atlassian, notamment Jira, Confluence et Bitbucket
- L’acteur de menace a mené des opérations de reconnaissance et accédé à des documents internes du 14 au 17 novembre, puis a installé Sliver le 22 novembre via ScriptRunner for Jira afin d’obtenir un accès persistant
- En réponse « Code Red », Cloudflare a renouvelé plus de 5 000 identifiants de production, effectué un triage forensique sur 4 893 systèmes, et réinstallé puis redémarré toutes les machines du réseau mondial ainsi que tous les produits Atlassian
- L’enquête indépendante de CrowdStrike n’a mis en évidence aucune activité manquée, et la dernière preuve d’activité malveillante a été confirmée au 24 novembre 2023 à 10:44 UTC
Vue d’ensemble de l’incident et périmètre d’impact
- Cloudflare a détecté un acteur de menace le 23 novembre 2023 sur ses serveurs Atlassian auto-hébergés
- L’équipe de sécurité a immédiatement lancé l’enquête et bloqué l’accès
- Le 26 novembre, l’équipe forensique de CrowdStrike a été sollicitée pour mener une analyse indépendante
- Les données clients et les systèmes clients n’ont pas été affectés par cet incident
- Les services n’ont pas été impliqués
- Aucun système du réseau mondial ni aucune modification de configuration n’ont été touchés
- Les contrôles d’accès, les règles de pare-feu et les clés de sécurité matérielles imposées par leurs outils Zero Trust internes ont limité les déplacements latéraux
- La portée de l’accès de l’acteur de menace s’est limitée au wiki interne Atlassian Confluence, à la base de bugs Jira, au système de gestion du code source Bitbucket, ainsi qu’aux serveurs sur lesquels Atlassian s’exécute
Identifiants utilisés pour l’intrusion
- L’intrusion a commencé à partir de 1 jeton de service et 3 comptes de service compromis lors de la compromission d’Okta d’octobre 2023, mais qui n’avaient pas été renouvelés
- Jeton de service Moveworks : utilisé pour l’accès distant aux systèmes Atlassian
- Compte de service Smartsheet : disposait de privilèges administrateur sur l’instance Atlassian Jira
- Compte de service Bitbucket : utilisé pour accéder au système de gestion du code source
- Compte d’environnement AWS : n’avait aucun droit d’accès au réseau mondial, aux données clients ni aux données sensibles
- Ces jetons et comptes avaient été exclus par erreur du renouvellement, car ils avaient été considérés comme inutilisés
- Cloudflare précise que ce problème ne résulte pas d’une erreur d’Atlassian, d’AWS, de Moveworks ou de Smartsheet, mais de l’échec de Cloudflare à renouveler ces identifiants
Chronologie de l’attaque
- Le 14 novembre à 09:22:49, l’acteur de menace a commencé l’exploration du système et la reconnaissance
- Une tentative de connexion à l’instance Okta a été refusée
- L’accès au Cloudflare Dashboard a également été bloqué
- Un accès a été obtenu à l’environnement AWS qui exécute la marketplace Cloudflare Apps, mais cet environnement était isolé du réseau mondial et des données clients
- Le 15 novembre à 16:28:38, l’accès à Atlassian Jira et Confluence a été obtenu avec succès
- Le passage par la passerelle a été réalisé avec le jeton de service Moveworks, puis l’accès à la suite Atlassian avec le compte de service Smartsheet
- Des recherches ont été effectuées dans le wiki sur
remote access,secret,client-secret,openconnect,cloudflared,token, etc. - 36 tickets Jira sur 2 059 357 et 202 pages wiki sur 194 100 ont été consultés
- Les tickets Jira consultés comprenaient des éléments liés à la gestion des vulnérabilités, à la rotation de secrets, au contournement MFA, à l’accès réseau et à la réponse à l’incident Okta
- Le 16 novembre à 14:36:37, à l’aide des identifiants Smartsheet, un compte Atlassian se présentant comme un utilisateur Cloudflare ordinaire a été créé, puis ajouté à plusieurs groupes
- L’objectif était de conserver l’accès à l’environnement Atlassian même si le compte de service Smartsheet était supprimé
- Du 17 novembre à 14:33:52 au 20 novembre à 09:26:53, l’accès aux systèmes Cloudflare a cessé, à l’exception de brefs tests d’accès
- Le 22 novembre à 14:18:22, les privilèges administrateur Jira du compte de service Smartsheet ont été utilisés pour installer, via le plugin ScriptRunner for Jira, le Sliver Adversary Emulation Framework
- Sliver est un outil et un framework utilisés par des red teams et des attaquants pour le C2, la connectivité et l’accès persistant et furtif
- Cela a permis d’obtenir un accès persistant aux serveurs Atlassian et de tenter des déplacements latéraux
- Une tentative d’accès à un serveur console non productif, situé dans un data center de São Paulo au Brésil et pas encore mis en production, a échoué
Accès au code source et aux documents
- Pendant la journée qui a suivi le 22 novembre, l’acteur de menace a consulté 120 dépôts de code sur 11 904
- Parmi eux, 76 dépôts ont été téléchargés vers les serveurs Atlassian à l’aide de la fonction
git archived’Atlassian Bitbucket - Cloudflare n’a pas pu confirmer une exfiltration externe, mais a réagi comme si elle avait eu lieu
- Parmi eux, 76 dépôts ont été téléchargés vers les serveurs Atlassian à l’aide de la fonction
- Les 76 dépôts concernaient principalement les domaines suivants
- Fonctionnement des sauvegardes
- Configuration et gestion du réseau mondial
- Système d’identité de Cloudflare
- Accès distant
- Utilisation de Terraform et de Kubernetes
- Certains dépôts contenaient des secrets chiffrés, et Cloudflare les a immédiatement renouvelés malgré leur chiffrement fort
- Cloudflare a concentré son enquête moins sur le code source lui-même que sur les secrets embarqués dans le code, les vulnérabilités et les chemins pouvant être exploités pour des attaques ultérieures
- Cloudflare explique avoir déjà publié une grande partie de son code en open source et avoir présenté publiquement, sur son blog, les algorithmes et techniques qu’elle utilise
Détection et blocage
- Le 23 novembre à 16:00, l’équipe de sécurité a reçu une alerte signalant la présence de l’acteur de menace
- 15:58 : l’acteur de menace a ajouté le compte de service Smartsheet au groupe des administrateurs
- 16:00 : une alerte automatique concernant ce changement a été transmise à l’équipe de sécurité
- 16:12 : le SOC de Cloudflare a commencé l’enquête
- 16:35 : désactivation du compte de service Smartsheet
- 17:23 : découverte puis désactivation du compte utilisateur Atlassian créé par l’acteur de menace
- 17:43 : déclaration interne d’incident chez Cloudflare
- 21:31 : application d’une règle de pare-feu bloquant les adresses IP connues de l’acteur de menace
- Le 24 novembre, la dernière activité et la suppression de Sliver ont été confirmées
- 10:44 : dernière activité connue de l’acteur de menace
- 11:59 : suppression de Sliver
- L’acteur de menace a tenté d’accéder à divers systèmes, notamment les métriques internes, la configuration réseau, les systèmes de build, les systèmes d’alerte et les systèmes de gestion des releases, mais sans succès
- Aucune preuve d’accès au réseau mondial, aux data centers, aux clés SSL, aux bases de données clients ou aux informations de configuration, à Cloudflare Workers, aux modèles d’IA, à l’infrastructure réseau, ni à des stockages de données comme Workers KV, R2 ou Quicksilver n’a été trouvée
Réponse « Code Red » et mesures de renforcement
- Après avoir expulsé l’acteur de menace de son environnement le 24 novembre, Cloudflare a mobilisé des équipes dans toute l’entreprise pour enquêter sur l’intrusion et confirmer l’étendue de l’accès
- À partir du 27 novembre, de nombreuses équipes techniques, au sein et en dehors de l’équipe sécurité, se sont concentrées sur le projet Code Red
- Renforcer, vérifier et corriger les contrôles de l’environnement en prévision de futures intrusions
- Vérifier que l’acteur de menace ne pouvait plus conserver d’accès
- Examiner tous les systèmes, comptes et journaux pour identifier d’éventuels accès persistants ainsi que les accès ou tentatives d’accès effectués
- Les principales mesures ont été les suivantes
- Renouvellement de plus de 5 000 identifiants de production
- Séparation physique des systèmes de test et de staging
- Triage forensique de 4 893 systèmes
- Réinstallation et redémarrage de toutes les machines du réseau mondial
- Réinstallation et redémarrage de tous les produits Atlassian, dont Jira, Confluence et Bitbucket
- Les équipements du data center de São Paulo ont été renvoyés au fabricant
- L’équipe forensique du fabricant a enquêté pour déterminer s’il y avait eu accès ou établissement d’une persistance
- Rien n’a été trouvé, mais Cloudflare a remplacé le matériel
- En complément, Cloudflare a examiné les paquets logiciels non mis à jour, les comptes utilisateurs potentiellement créés, les comptes employés encore actifs mais inutilisés, les secrets pouvant subsister dans les tickets Jira ou le code source, ainsi que les fichiers HAR téléversés sur le wiki
- Les fichiers HAR ont été supprimés par précaution, car ils pouvaient contenir des jetons
- Les travaux immédiats de Code Red se sont achevés le 5 janvier 2024, mais les efforts liés à la gestion des identifiants, au durcissement logiciel, à la gestion des vulnérabilités et à l’amélioration des alertes se poursuivent
Enquête CrowdStrike et IOCs
- CrowdStrike a évalué de manière indépendante l’étendue de l’activité de l’acteur de menace et les preuves de persistance
- Aucune activité manquée par l’enquête de Cloudflare n’a été découverte
- La dernière preuve d’activité malveillante a été fixée au 24 novembre 2023 à 10:44 UTC
- Cloudflare estime, sur la base de sa collaboration avec des pairs du secteur et des autorités, que cette attaque a été menée par un acteur soutenu par un État, cherchant à obtenir un accès durable et étendu au réseau mondial de Cloudflare
- Cloudflare a publié des indicateurs de compromission afin que d’autres organisations potentiellement touchées par la compromission d’Okta puissent vérifier leurs journaux
193.142.58[.]126: infrastructure principale de l’acteur de menace, détenue par M247 Europe SRL198.244.174[.]214: serveur C2 Sliver, détenu par OVH SASidowall[.]com: infrastructure de diffusion de la charge utile Sliverjvm-agent: nom du fichier de la charge utile Sliver, SHA256bdd1a085d651082ad567b03e5186d1d46d822bb7794157ab8cce95d850a3caaf
1 commentaires
Avis sur Hacker News
C’est grâce à ce type d’analyse publique et de réponse de Cloudflare que je peux leur confier mes données et mon activité.
Ils ne sont pas parfaits, et il y a des choses avec lesquelles je ne suis pas d’accord, mais l’état d’esprit d’ingénierie partagé dans toute l’entreprise et leur manière de prendre ces sujets au sérieux me donnent confiance.
La méthode consiste à souligner qu’ils ont une intégrité supérieure à celle de leurs concurrents, et à partager quelques enquêtes opérationnelles après un incident de sécurité récent.
Mais Cloudflare ne fournit pas d’analyse des risques SOC en tant que prestataire de traitement de cartes de paiement PCI/DSS, et n’explique pas pourquoi ils ont manqué les comptes dont les privilèges avaient été élevés, ni comment ces comptes ont été compromis au départ. Ils expliquent la remédiation plutôt que les responsabilités.
Ils mentionnent un audit tiers, mais ce n’est pas par souci des utilisateurs : c’est parce que PCI/DSS impose un audit sur site annuel aux organisations dont les données de cartes de paiement ont été compromises. Sinon, les grands réseaux de cartes auraient cessé de traiter leurs paiements.
J’ai du mal à croire qu’ils n’aient rien perdu ; la plupart des Jira/Confluence que j’ai vus regorgeaient d’informations sensibles.
Quand on lit « en analysant les pages wiki, les tickets de base de bugs et les dépôts de code source consultés, il semble qu’ils cherchaient des informations sur l’architecture, la sécurité et la gestion du réseau mondial », la méthode la plus simple pour un acteur étatique consiste à faire entrer un citoyen loyal comme employé dans l’entreprise ciblée, puis à lui faire transmettre ces informations.
Anecdote amusante, mais dont la véracité est incertaine : il y a plus de dix ans, lors d’une rencontre informelle entre SRE de Google, quelques personnes auraient reconnu être rémunérées par les services de renseignement de leur pays.
Sinon, je me demande quelle drogue circulait dans cette rencontre pour qu’un échec aussi catastrophique de sécurité opérationnelle se produise.
Les Australiens ont « l’occasion » de participer à ce genre d’espionnage presque comme une condition de base de la citoyenneté : https://en.wikipedia.org/wiki/Mass_surveillance_in_Australia...
L’avantage, c’est que cela peut aider à imposer de bonnes pratiques dans le développement de procédures et de systèmes zero trust.
La partie « nous avons été victimes pour la deuxième fois de la compromission du système Okta » me fait me demander si Cloudflare est en train de réévaluer son usage d’Okta.
Okta mérite aussi des critiques, mais ici j’ai l’impression que Cloudflare rejette la faute vers le bas pour couvrir sa propre erreur.
J’utilise encore un vieux MacBook reçu « au tout début », donc sans aucun logiciel de gestion. À l’époque, il n’y avait pas d’IT et on m’avait juste donné un portable neuf, intact.
L’entreprise m’a proposé de passer à un M1/M2 Pro, mais j’ai refusé parce que je ne veux pas utiliser le système de connexion Okta s’il y a ne serait-ce qu’un seul mot de passe ou une seule clé personnelle sur mon ordinateur de travail.
Je ne pourrai donc pas faire la mise à niveau tant que cela ne gênera pas sérieusement mon travail. Je pourrais peut-être utiliser ce genre d’incident pour justifier ma position auprès du service IT.
La phrase « un jeton de service et trois comptes n’ont pas été renouvelés parce que nous pensions à tort qu’ils n’étaient pas utilisés » est étrange. S’ils n’étaient pas utilisés, pourquoi ne pas les avoir purement et simplement supprimés ?
Il manque probablement quelque chose, ou un élément s’est perdu dans la communication, mais prise telle quelle, la phrase n’est pas très compréhensible.
Par exemple, il est possible que, quelque part dans une base de données, ce compte de service ait été marqué avec un état inactif du type « supprimé » ou « nettoyé », mais que cette indication soit erronée. Ils auraient donc fait tourner les mots de passe de tous les comptes actifs et ignoré les comptes inactifs.
Si je me limite au contexte des infrastructures à clé publique et de la révocation de certificats, que je connais bien, laisser expirer un certificat, le marquer comme « plus utilisé » et le révoquer complètement sont des choses assez différentes. Dans le premier cas, l’autorité de certification n’a rien à faire ; dans le deuxième, elle peut ne rien faire ou révoquer ; dans le troisième, elle doit maintenir et distribuer activement une liste de révocation. Si quelqu’un dit « j’ai accidentellement écrasé ma clé privée, donnez-moi un certificat pour une nouvelle clé », on ne met généralement pas l’ancien certificat sur une liste de révocation.
Le fait qu’ils aient écrit clairement « ce n’est absolument pas une erreur d’AWS, de Moveworks ou de Smartsheet ; il s’agit simplement d’identifiants que nous n’avons pas réussi à renouveler » est une bonne précision.
Cloudflare pensait, et a confirmé plus tard, que l’accès de l’attaquant était limité, mais a tout de même procédé à la rotation de plus de 5 000 identifiants de production, séparé physiquement les systèmes de test et de staging, effectué une analyse forensic de 4 893 systèmes, et réimagé puis redémarré toutes les machines de son réseau mondial
Une tentative d’accès au serveur console du datacenter de São Paulo, qui n’était pas encore passé en production, a également échoué, mais Cloudflare a renvoyé l’équipement du datacenter brésilien au fabricant pour analyse forensic et, bien que rien n’ait été trouvé, a remplacé le matériel
Ils n’étaient pas obligés d’aller aussi loin, et il aurait été facile de ne pas le faire ; le fait qu’ils l’aient réellement fait mérite des éloges
S’infiltrer dans les premières phases de construction d’un nouveau datacenter, c’est presque l’exploit ultime. Il suffit d’imaginer quelqu’un au beau milieu d’une nouvelle Meet-Me room(https://en.wikipedia.org/wiki/Meet-me_room) obtenant un accès persistant aux switches principaux
Les datacenters de Cloudflare sont souvent des hubs d’un volume énorme de trafic de données. Le fait que l’attaquant ait compris la valeur d’un datacenter « pré-production » signifie probablement que Cloudflare a aussi compris qu’un point d’appui là-bas, avant la mise en place du dispositif de sécurité normal, équivaut à 100 % à un game over. Si quelqu’un parvient à s’installer dans un datacenter en cours de construction ou de démarrage, c’est un incident qui peut mettre fin à l’entreprise
Il faut aussi garder en tête qu’au début de la construction d’un datacenter, tous les switches et équipements utilisent des valeurs par défaut ou des mots de passe root vides (admin/admin), avec des firmwares anciens et remplis de vulnérabilités. Si ce type d’attaque se produit avant que l’automatisation n’ait patché l’ensemble des firmwares, on est au niveau de « renvoyons tout l’équipement et demandons au fabricant d’en envoyer du neuf »
Si l’on suppose que l’attaquant n’a accédé qu’au périmètre prouvable, on lui laisse des ouvertures pour survivre. Pour dire qu’il n’est pas nécessaire de faire cela, il devrait falloir l’approbation d’un quorum de plusieurs personnes
Bien sûr, c’est dans un monde idéal. Je m’estime déjà heureux que mon équipe obtienne du temps pour implémenter des fonctionnalités qui n’apportent pas de bénéfice financier ou utilisateur direct
Être prêt à exécuter ce type de rotation d’identifiants exige de la discipline et de la préparation, et honnêtement la plupart des équipes ne font pas cet investissement. Même les équipes intelligentes et bien dotées
Si l’équipe sécurité de Cloudflare peut décider de faire tourner tous les secrets et de réimager toutes les machines, et que cela se produit réellement dans un délai raisonnable, c’est assez impressionnant
† https://twitter.com/badthingsdaily?lang=en
La partie la plus surprenante ici, c’est que Cloudflare utilise Bitbucket
Une fois qu’une fuite de données est sortie, dans ce cas précis le code source est définitivement dehors, et on n’a absolument aucun contrôle sur qui le récupère
On peut renforcer autant qu’on veut après l’incident et en parler tant qu’on veut, ce qu’on voulait empêcher s’est déjà produit. On ne peut pas remettre un œuf battu dans sa coquille
On peut aussi trouver d’autres easter eggs dans du vieux code. Presque toutes les entreprises ont des backdoors non documentées
Une fuite de données clients serait pire, mais ça reste vraiment mauvais
Les données clients de l’an prochain ne sont pas non plus les mêmes que celles de cette année
Dans Confluence d’Atlassian, le simple moteur de recherche Apache Lucene intégré peut déjà faire fuiter des informations sensibles, et ce type d’accès peut être très difficile à tracer et à identifier
Si les informations sensibles apparaissent déjà sur la page de résultats de recherche, l’attaquant n’a même pas besoin d’ouvrir la page Confluence
Le passage disant qu’« un jeton de service et trois comptes n’ont pas été renouvelés parce qu’ils étaient considérés à tort comme inutilisés » est étrange. Des identifiants inutilisés devraient probablement être supprimés, pas renouvelés
Une situation du genre : « C’est quoi ces comptes ? » « Ah, ils ne sont pas utilisés. Ils n’apparaissent même pas dans les logs » « Il faut quand même les faire tourner » « Non, laissons juste ces comptes arbitraires avec d’anciens identifiants potentiellement compromis… pour des raisons plus ou moins vagues » ?
Après l’incident Okta, s’ils ont fait tourner les identifiants divulgués, je pense qu’ils auraient dû mettre un honeypot dessus et attendre de voir ce que les attaquants feraient
Un honeypot a aussi pour effet de freiner les attaquants, qui craignent d’être repérés