Cloudflare défend à elle seule 20 % d’Internet environ. Pour rappel, cette société américaine s’est fait une spécialité de la protection des sites et services d’une ribambelle d’attaques, au premier rang desquelles le déni de service distribué (DDoS). Aussi, quand une société spécialisée dans la cyberdéfense subit une attaque, la situation est à examiner à la loupe.

L’incident s’est produit aux alentours du dernier Thanksgiving. Des acteurs malveillants ont réussi à entrer dans l’un des réseaux, profitant notamment d’informations d’identification volées. À la suite de cette intrusion, Cloudflare a fait appel à CrowdStrike, société spécialisée elle aussi dans la sécurité, plus particulièrement dans les outils de réponses aux attaques. Elle a rendu son rapport à Cloudflare le 31 janvier.

Début des hostilités

L’attaque a commencé un peu après 9 heures du matin, heure locale. À ce moment, un ou plusieurs pirates sondent les systèmes de Cloudflare. Ils se servent pour cela d’informations d’identification dérobées lors de l’attaque d’Okta, le mois précédent. Cloudflare précise que toutes ces informations devaient faire l’objet d’une rotation. « Malheureusement, nous n'avons pas changé un jeton de service et trois comptes de service (sur des milliers) », ajoute l’entreprise. Pourquoi ? Car elle pensait à tort que ces informations étaient inutilisées.

Ces informations n’ont pas permis de se connecter à l’instance Okta hébergée par Cloudflare, pas plus qu’au tableau de bord. L’acteur malveillant a pu entrer dans un environnement AWS, utilisé pour la boutique Cloudflare Apps. L’environnement étant coupé du reste, l’acteur n’a eu accès à rien d’autre. Le compte utilisé pour se connecter a été révoqué.

Entrent alors en piste les informations précédemment dérobées. « L'acteur malveillant a réussi à accéder à Atlassian Jira et Confluence le 15 novembre en utilisant le jeton de service Moveworks pour s'authentifier via notre passerelle, puis a utilisé le compte de service Smartsheet pour accéder à la suite Atlassian », explique Cloudflare.

Récolte d’informations et création de compte

Le 16 novembre, les pirates commencent à se balader dans les installations pénétrées, en vue de dénicher des informations sur le type de configuration. Ils ont également cherché des renseignements sur la gestion du réseau mondial de Cloudflare.

Les pirates ont pu accéder à 36 tickets Jira (sur plus de 2 millions) et 202 pages du wiki (sur plus de 194 000). Les recherches étaient précises. Dans les tickets, les pirates voulaient des informations sur la gestion des failles, la rotation des secrets (dont les jetons bien sûr), le contournement de l’authentification à facteurs multiples, l’accès au réseau, jusqu’à la propre réponse de Cloudflare à l’incident chez Okta le mois précédent. Dans le wiki, ils ont regardé dans la politique de réinitialisation des mots de passe, l’accès à distance, la configuration générale ou encore l’utilisation de Salt. Mais pas les données et configurations des clients.

Le 17 novembre, les pirates créent un compte Atlassian en utilisant les informations d’identification Smartsheet. Le compte est maquillé pour ressembler aux autres et se faire discret. Il a tout de même été ajouté à plusieurs groupes pour obtenir un accès permanent à Atlassian.

Pause et montée en puissance

Après la création du compte, les pirates ne font plus rien pendant trois jours. Seule exception, un petit test pour vérifier que l’accès créé était toujours là.

Dans les jours qui suivent, l’acteur malveillant parvient à installer le Sliver Adversary Emulation Framework, via l’outil ScriptRunner d’Atlassian Jira. Ce cadriciel est traditionnellement utilisé pour les communications avec un serveur C&C (ou C2, pour « command and control »).

À partir de là, et après avoir conforté leur position dans l’environnement Atlassian, les pirates ont tenté des manœuvres latérales. Une tentative classique : les intrus profitent d’un accès dans un système pour vérifier s’ils peuvent s’étendre à d’autres. Ils ont notamment tenté d’accéder à un serveur de console dans le datacenter de Sao Paulo, non finalisé. Bien qu’ayant pu essayer via une liste de contrôle non renforcée, l’accès leur a été refusé.

Les pirates ont pu cependant consulter 120 référentiels de code (sur 11 904). 76 ont fait l’objet d’un archivage (via Atlassian Bitbucket) pour qu’ils puissent être téléchargés par la suite. Cloudflare dit ne pas savoir si ces données ont réellement été exfiltrées, mais les a traitées comme telles.

« Les 76 dépôts de code source étaient presque tous liés au fonctionnement des sauvegardes, à la configuration et à la gestion du réseau mondial, au fonctionnement de l'identité chez Cloudflare, à l'accès à distance et à notre utilisation de Terraform et de Kubernetes. Un petit nombre de référentiels contenait des secrets chiffrés qui ont fait l'objet d'une rotation immédiate, même s'ils étaient eux-mêmes fortement chiffrés », explique l’entreprise.

Précisons qu’une grande partie du code utilisé chez Cloudflare est open source (licences Apache, BSD ou MIT selon les projets).

Un petit tour et puis s’en va

L’entreprise indique avoir été avertie par son équipe de sécurité le 23 novembre à 16 h (toujours heure locale). 35 minutes plus tard, le compte de service Smartsheet était coupé. Encore 48 minutes après, le compte Atlassian créé par les pirates a été trouvé et désactivé. À 17h43, l’incident interne était déclaré. À 21h30, des règles spécifiques sont ajoutées au pare-feu de l’entreprise pour bloquer les adresses IP utilisées par les pirates.

« Pour être clair, nous n'avons vu aucune preuve que l'acteur malveillant ait eu accès à notre réseau mondial, à nos centres de données, à nos clés SSL, aux bases de données de nos clients ou aux informations de configuration, aux employés Cloudflare que nous ou nos clients ont déployés, aux modèles d'IA, à l'infrastructure du réseau ou à l'un de nos entrepôts de données comme Workers KV, R2 ou Quicksilver. Leur accès était limité à la suite Atlassian et au serveur sur lequel elle tourne », résume Cloudflare.

Une attaque soutenue par un État ?

Évidemment, quand un acteur aussi visible que Cloudflare écope d’une attaque, tous les regards sont braqués sur le rapport post-mortem.

Pour la société, il s’agissait d’un « incident de sécurité impliquant un acteur sophistiqué, probablement un État ». Le mode opératoire est décrit comme « réfléchi et méthodique ». Pendant plus d’un mois, « un grand nombre d’ingénieurs » a travaillé exclusivement à cette crise, dont l’entreprise dit avoir fait « sa priorité ».

L’exercice de communication est toujours intéressant à observer. Ce type de rapport sert plusieurs objectifs dont, bien sûr, rassurer les clients. Il est également très utile pour diffuser des connaissances en jouant le jeu de la transparence.