Le 23 novembre dernier, l’éditeur Cloudflare détectait une intrusion sur son serveur Atlassian auto-hébergé. En cause, des comptes de service compromis lors d’une précédente attaque d’Okta. Les attaquants ont eu accès au wiki Confluence, à la base de données Jira et à une partie du code source hébergé sur Bitbucket. Éric Fourrier, CEO de GitGuardian revient sur cet incident.
Le 14 novembre, un attaquant, vraisemblablement soutenu par un État, a infiltré le serveur Atlassian de Cloudflare, compromettant son wiki Confluence, sa base de données Jira, et son système de gestion de code source Bitbucket. Dès le début de l’attaque, les pirates ont établi un accès continu au serveur Atlassian de Cloudflare à l’aide de l’outil Jira ScriptRunner. Les attaquants ont utilisé un jeton d’accès et trois identifiants de compte de service obtenus lors de la précédente violation de Okta en octobre 2023. En octobre 2023, Okta a révélé que son système de support avait été attaqué et que des fichiers HTTP Archive (HAR) téléchargés par les clients avaient été consultés, incluant des jetons de session et les cookies de ses clients. Okta a révoqué les jetons de session et a conseillé à ses clients de nettoyer ces fichiers. BeyondTrust et Cloudflare ont tous les deux détecté une activité malveillante liée à cet incident peu de temps après et ont pu y répondre rapidement. Cloudflare a malheureusement réalisé plus tard que certains jetons d’accès n’avaient pas été correctement renouvelés.
Un besoin urgent de gérer la dissémination des secrets
*L’échec de Cloudflare à désactiver ces secrets compromis a été un facteur principal facilitant l’attaque suivante. Alors que les tentatives pour infiltrer le centre de données de São Paulo de Cloudflare ont échoué, des données sensibles ont été exfiltrées. Un examen exhaustif des documents consultés suggère que les pirates cherchaient des données complètes sur l’architecture, la sécurité, et la gestion du réseau global de Cloudflare. Bien que Cloudflare ait conclu que les données de ses clients et les systèmes de son réseau global n’étaient pas touchés, les implications sont graves. “Même si nous comprenons que l’impact opérationnel de l’incident est extrêmement limité, nous avons pris cet incident très au sérieux car un acteur a utilisé des identifiants volés pour accéder à notre serveur Atlassian et a consulté une documentation et une quantité limitée de code source”, Prince, Graham-Cumming, et Bourzikas. Cet incident souligne les défis de sécurité redoutables auxquels les entreprises font face, y compris le besoin urgent de gérer la dissémination des secrets et de détecter les intrusions dès que possible pour éviter des impacts similaires.
Analyse de l’incident
Cet incident illustre de manière frappante la menace réelle posée par des secrets éparpillés à sur diverses plateformes de manière incontrôlée. Elle montre que même les entreprises réputées pour leur haut niveau de sécurité, comme Cloudflare, ne sont pas à l’abri de subir des attaques si les secrets ne sont pas correctement sécurisés. Dans le cas de Cloudflare, les attaquants se sont déplacés d’un secret compromis à un autre, ce qui bien montre comment les secrets servent de points de pivot dans les chaînes d’attaque. Depuis l’obtention d’un premier d’entrée chez un service d’authentification tiers (Okta) jusqu’à l’infiltration d’une cible (Cloudflare), les pirates ont finalement pu collecter encore davantage de secrets lors des phases de reconnaissance. Si une équipe n’est pas consciente que des secrets (informations d’authentication telles que les clés d’API ou les clés privées) de son organisation ont été exposés et qu’ils ont besoin d’être révoqués, ils ne seront jamais corrigés. La plateforme de détection de secrets GitGuardian est conçue pour aider les entreprises à résoudre ce problème précis. Avec plus de 400 détecteurs adaptés aux entreprises, il est possible rapidement d’identifier où se trouvent n’importe quels secrets dans le code ou dans les instances Slack et (bientôt) Jira.
Vérifier la validité d’un jeton
Une fois que l’on sait qu’un secret a été exposé, il est indispensable de le changer, en espérant que cela se produise avant une exploitation. La plateforme aide également à suivre les efforts de remédiation, en donnant une chronologie claire de quand l’identifiant a été ajouté à la base de code ou mentionné pour la première fois dans un canal Slack. La plateforme donne également un moyen de vérifier rapidement si un jeton est valide et s’il a été exposé publiquement sur GitHub, permettant d’attribuer rapidement des priorités. Une fois l’incident résolu, l’organisation à un enregistrement de toutes les étapes suivies et peut être assurée que le risque a été réduit. L’équipe de Cloudflare a été transparente et a travaillé rapidement pour protéger leurs clients. Bien qu’un temps d’investigation de neuf jours soit plus court que la moyenne, l’efficacité d’une réponse pour mitiger ce genre d’attaque dépend en grande partie du temps écoulé entre l’intrusion et sa détection. La meilleure défense ici est de tromper les attaquants pour qu’ils se dévoilent eux-mêmes.
Des faux identifiants pour leurrer les attaquants
C’est justement l’intérêt des honeytokens, de faux identifiants disséminés dans les environnements digitaux afin de leurrer des attaquants. Ces dispositifs permettent d’être alerté en temps réel lors d’une phase de reconnaissance. Ils n’ont aucune utilisation légitime, mais lorsque quelqu’un essaie d’en utiliser un, des alarmes se déclenchent, et l’on peut obtenir l’adresse IP, l’agent utilisateur, et les actions que l’utilisateur, ou plus probablement l’outil scripté, essayait d’exécuter. Les honeytokens peuvent être déployés à grande échelle dans les environnements. Dans le cas où des intrus se déplaçeraient à travers différents systèmes, il est très probable qu’ils essairaient d’exploiter tous les secrets qu’ils auraient trouvés, se révélant ainsi à l’étape 3 plutôt qu’à l’étape si nous reprenons les étapes mentionnées dans le résumé. Cet incident souligne les graves dangers auxquels on peut s’exposer en sous-estimant la menace que représente la dissémination incontrôlée des secrets. C’est un rappel important que la cybersécurité est une responsabilité partagée qui doit s’étendre à toute la chaîne d’approvisionnement. Pour sécuriser réellement nos actifs numériques, il doit y avoir un contrôle strict de la gestion des secrets, ainsi que des mises à jour ou rotations rapides chaque fois qu’un incident se produit.
Éric Fourrier, CEO de GitGuardian
