« Notre objectif était d'empêcher l'attaquant d'utiliser les informations techniques sur le fonctionnement de notre réseau comme moyen d'y revenir », a expliqué Cloudflare lors de son analyse post-mortem de la cyberattaque du novembre. (crédit : Cloudlare)
Le fournisseur de solutions de CDN et de services de sécurité Cloudlfare a expliqué comment des pirates bénéficiant d'un soutien de niveau étatique sont parvenus à pénétrer sur son serveur interne Atlassian en utilisant des informations d'identification volées lors d'une faille de sécurité chez Okta en octobre dernier. Un plan baptisé Code Red a été activé pour éviter qu'un incident de ce type se reproduise.
Le 23 novembre 2023 (jour de la thanskgiving aux Etats-Unis), CloudFlare a détecté un accès malveillant sur son serveur Atlassian interne. Epaulé par Crowdstrike spécialisé en analyse forensics,le fournisseur a remonté le fil de la pelote sur cet incident de sécurité et en a fait un résumé dans un dernier billet de blog. Après avoir rappelé au passage qu'aucune donnée ni systèmes de ses clients n'ont été affectés par ce piratage, le fournisseur a expliqué que du 14 au 17 novembre dernier, un acteur malveillant a fait de la reconnaissance avant d'accéder à son wiki interne ainsi qu'à sa base de données de bugs reposant tous les deux sur des solutions Atlassian, à savoir respectivement Confluence et Jira, installées sur un serveur.
« Les 20 et 21 novembre, nous avons constaté des accès supplémentaires indiquant qu'ils sont peut-être revenus pour tester l'accès afin de s'assurer qu'ils avaient la connectivité », fait savoir le fournisseur de solutions de CDN et de services de sécurité. « Ils sont ensuite revenus le 22 novembre et ont établi un accès persistant à notre serveur Atlassian en utilisant ScriptRunner pour Jira, ont accédé à notre système de gestion du code source qui s'appuie sur Atlassian Bitbucket et ont essayé, sans succès, d'accéder à un serveur de console qui avait accès au datacenter que Cloudflare n'avait pas encore mis en production à São Paulo, au Brésil ». Pour cela, les pirates se sont servis d'un token d'accès et trois identifiants de service issus de la compromission d'Okta le mois précédent - qui s'est avéré plus grave qu'annoncé - mais n'ont donc pas pu aller plus loin, sachant que la dernière trace de leur activité a été établie au 24 novembre 2023.
76 dépôts de code source dans le viseur des pirates
« En analysant les pages wiki auxquelles ils ont accédé, les base de données de bogues et les dépôts de code source, il apparaît qu'ils cherchaient des informations sur l'architecture, la sécurité et la gestion de notre réseau mondial, sans doute dans le but de s'implanter plus profondément », relate Cloudflare. L'impact opérationnel est apparu limité mais loin d'être insignifiant : 120 dépôts de code sont concernés - dont 76 pour lesquels la fonction d'archivage a été utilisé sans savoir si les pirates sont parvenus à les exfiltrer - sur un total de 11 904. Mais cela n'a rien d'anecdotique : les 76 dépôts de code source candidats au leak ou réellement exfiltrés étaient en effet presque tous liés au fonctionnement des sauvegardes, à la configuration et à la gestion du réseau mondial, au fonctionnement de l'identité de Cloudflare, à l'accès à distance et à son usage de Terraform et de Kubernetes. Sachant qu'un petit nombre de référentiels contenait des secrets chiffrés ayant fait l'objet d'une rotation immédiate même s'ils étaient eux-mêmes fortement chiffrés. Soit de précieuses données pour des pirates qui s'avèrent particulièrement expérimentés.
Si de prime abord l'impact opérationnel apparait sans commune mesure avec ce qu'il aurait pu être si les pirates étaient parvenus à accéder au serveur de console connecté à son datacenter, Cloudflare n'est pas passé loin du drame. Il faut dire que le pédigré des acteurs malveillants qui étaient aux manettes n'a rien à voir avec des cybercriminels novices : « sur la base de notre collaboration avec des collègues de l'industrie et du gouvernement, nous pensons que cette attaque a été menée par un État dans le but d'obtenir un accès persistant et généralisé au réseau mondial de Cloudflare », affirme le fournisseur.
Opération Code Red pour tout vérifier et tout verrouiller
Suite à cet incident, Cloudlfare a concentré ses efforts jusqu'au 5 janvier 2024 dans un projet baptisé « code red » pour renforcer ses protocoles de sécurité afin d'empêcher l'acteur de la menace de pénétrer son réseau, mais aussi valider et remédier à tout contrôle dans son environnement pour garantir sa sécurité contre toute intrusion future. « Nous nous sommes particulièrement concentrés sur ces 76 dépôts de code source afin de rechercher des secrets intégrés (les secrets stockés dans le code ont fait l'objet d'une rotation), des vulnérabilités et des moyens par lesquels un attaquant pourrait les utiliser pour monter une attaque ultérieure », indique Cloudflare.
Dans le cadre de cette opération, chaque membre de l'équipe a été encouragé à indiquer les zones que l'attaquant aurait pu toucher. « En faisant appel à un si grand nombre de personnes au sein de l'entreprise, nous avons cherché à ne négliger aucune piste pour trouver des preuves d'accès ou des changements à apporter pour améliorer la sécurité », poursuit Cloudflare. « Notre objectif était d'empêcher l'attaquant d'utiliser les informations techniques sur le fonctionnement de notre réseau comme moyen d'y revenir [...] nous avons entrepris une vaste opération de rotation de toutes les informations d'identification de la production (plus de 5 000 informations d'identification individuelles), segmenté physiquement les systèmes de test et de préparation, effectué des inventaires pour le forensic sur 4 893 systèmes, réimagé et redémarré chaque machine de notre réseau mondial, y compris tous les systèmes auxquels l'acteur de la menace a accédé et tous les produits Atlassian (Jira, Confluence, et Bitbucket) ».
Suivez-nous