Incident de sécurité de Thanksgiving 2023

Incident de sécurité de Thanksgiving 2023

• Le 23 novembre 2023, jour de Thanksgiving, Cloudflare a détecté un acteur malveillant sur des serveurs Atlassian auto-hébergés.
• L'équipe de sécurité a immédiatement lancé une enquête et bloqué l'accès de l'acteur malveillant.
• Le 26 novembre, l'équipe forensique de CrowdStrike a été sollicitée pour mener une analyse indépendante.
• CrowdStrike a terminé son enquête et Cloudflare partage, dans ce billet de blog, les détails de l'incident de sécurité.
• Cloudflare souligne qu'aucune donnée client ni aucun système client n'ont été affectés par cet incident.
• Les contrôles d'accès, les règles de pare-feu et l'application obligatoire de clés de sécurité matérielles via des outils Zero Trust ont limité la capacité de déplacement latéral de l'acteur malveillant.

Travaux de récupération et de renforcement « code red »

• Une fois l'acteur malveillant éliminé de l'environnement, l'équipe de sécurité a mobilisé toutes les personnes nécessaires à l'échelle de l'entreprise pour terminer l'enquête sur l'intrusion et le blocage des accès.
• À partir du 27 novembre, des équipes techniques ont été mobilisées pour se concentrer sur un projet nommé "code red".
• L'objectif de ce projet était de renforcer et de vérifier tous les contrôles de l'environnement afin de se préparer à de futures intrusions et d'empêcher l'acteur malveillant d'y accéder à nouveau.
• CrowdStrike a réalisé une évaluation indépendante de l'étendue et de l'ampleur des activités de l'acteur malveillant.

Chronologie de l'attaque

• L'attaque a commencé avec la compromission de sécurité d'Okta en octobre, et à partir de la mi-novembre, l'acteur malveillant a ciblé les systèmes de Cloudflare à l'aide d'identifiants obtenus lors de cette compromission.
• Le 18 octobre, la compromission d'Okta a permis à l'acteur malveillant d'accéder à des identifiants.
• À partir du 14 novembre, l'acteur malveillant a commencé à explorer les systèmes et à tenter d'y accéder.
• Le 15 novembre, il a réussi à accéder à Atlassian Jira et Confluence.
• Le 16 novembre, il a créé un compte utilisateur Atlassian.
• Du 17 au 20 novembre, il n'a pas accédé aux systèmes de Cloudflare.
• Le 22 novembre, il a installé Sliver Adversary Emulation Framework afin de maintenir un accès persistant.
• Le 23 novembre, l'équipe de sécurité a détecté la présence de l'acteur malveillant et a commencé à bloquer les accès.

Conclusion

• Cet incident serait le fait d'un acteur étatique, et Cloudflare a déployé d'importants efforts pour en limiter l'impact et se préparer à de futures attaques.
• L'équipe d'ingénierie de Cloudflare a protégé les systèmes, cherché à comprendre l'accès obtenu par l'acteur malveillant, traité les priorités immédiates et établi un plan pour améliorer la sécurité globale.
• CrowdStrike a mené une évaluation indépendante et, une fois son rapport final achevé, Cloudflare a publié ce billet de blog avec confiance dans son analyse interne et dans les mesures prises face à l'intrusion.

Avis de GN⁺ :

1. Cet incident souligne l'importance de l'architecture Zero Trust de Cloudflare. Elle fonctionne en limitant la propagation des menaces à l'ensemble de l'organisation grâce à l'isolation entre les systèmes.
2. La rapidité de réaction de Cloudflare et ses efforts de renforcement de la sécurité via le projet "code red" donnent un aperçu concret de la manière dont une entreprise peut répondre à des menaces de cybersécurité.
3. Cet article constitue un cas instructif pour comprendre comment une organisation peut réagir à un incident de cybersécurité et quelles mesures elle doit prendre.

[GN⁺]

Avis sur Hacker News

• Pourquoi des actions comme le billet de blog de Cloudflare inspirent confiance

  • Cloudflare n’est pas parfait, mais son approche d’ingénierie et sa manière de gérer les problèmes graves le rendent digne de confiance.
  • Expression de remerciement pour le billet de blog.

• Le problème des fuites de données

  • Une fois que des données ont fuité, elles deviennent définitivement impossibles à contrôler.
  • Le travail de renforcement et les échanges après l’incident sont importants, mais ne peuvent pas empêcher ce qui s’est déjà produit.

• Les problèmes de sécurité du système Okta

  • Inquiétude face au fait qu’Okta ait été touché une deuxième fois.

• Les jetons de service et comptes non renouvelés

  • Ils n’ont pas été renouvelés parce qu’on croyait à tort qu’ils n’étaient pas utilisés.
  • Questionnement sur les raisons pour lesquelles ils n’ont pas été complètement révoqués.

• L’accès limité de l’attaquant et les mesures de réponse

  • Bien qu’il ait été estimé que l’accès de l’attaquant était limité, des mesures très larges ont été prises, comme le renouvellement de tous les identifiants de production, l’analyse forensique des systèmes, ainsi que leur réimaging et leur redémarrage.
  • Une tentative d’accès à de nouveaux systèmes dans le datacenter brésilien a échoué, et l’équipement a été renvoyé au fabricant pour inspection et remplacement.

• Analyse des objectifs de l’attaquant

  • À travers l’analyse de pages wiki, d’une base de données de bugs et de dépôts de code source, il semble que l’attaquant cherchait des informations sur l’architecture, la sécurité et l’administration du réseau mondial de Cloudflare.

• Surprise quant à l’utilisation de BitBucket par Cloudflare

  • Expression de surprise face au fait que Cloudflare utilise BitBucket.

• Traitement des identifiants considérés comme inutilisés

  • Pour des identifiants considérés comme inutilisés, leur suppression aurait été plus appropriée qu’un simple renouvellement.

• Proposition de renouvellement des identifiants et de honeypot après l’incident Okta

  • Proposition d’utiliser un honeypot après avoir renouvelé les identifiants compromis, afin d’observer le comportement de l’attaquant.

• Interrogation sur le zero trust (ZT)

  • Il est souligné que le fait de pouvoir accéder à une application avec un seul bearer token ne correspond pas à la définition du zero trust.

Contexte : Cloudflare est une entreprise qui fournit des services de sécurité Internet et des services DNS distribués, tandis qu’Okta fournit des services de gestion des identités et des accès. Le zero trust est un modèle de sécurité réseau qui consiste à ne faire confiance par défaut à aucun utilisateur ni appareil et à exiger une vérification systématique.