Cloudflare a publié un rapport sur le piratage de l'un des serveurs 

pirate

Un hacker a réussi à compromettre l'infrastructure

Cloudflare dévoilé via un article de blog, un rapport sur le hack de l'un des serveurs de son infrastructure, le rapport détaille l'incident survenu le "Thanksgiving Day 2023" et note que le 23 novembre 2023, Un pirate informatique a accédé au serveur Atlassian auto-hébergé de l'entreprise.

Ce serveur exploité un site wiki interne basé sur la plateforme Atlassian Confluence, le système de suivi des problèmes Atlassian Jira et le système de gestion de code Bitbucket. L'analyse a révélé que l'attaquant a pu accéder au serveur à l'aide de jetons obtenus à la suite du piratage d'Okta en octobre, ce qui a entraîné la fuite des jetons d'accès.

Après la divulgation du piratage d'Okta, Cloudflare a commencé le processus de mise à jour des informations d'identification, des clés et des jetons utilisés via les services Okta. Cependant, Il a été découvert qu'en conséquence, un jeton et trois comptes (parmi plusieurs milliers) ils sont restés engagés et c’est parce que ces identifiants n’ont pas été remplacés que l’attaquant a profité de cet oubli.

Nous souhaitons souligner à nos clients que cet événement n'a pas eu d'impact sur les données ou les systèmes des clients Cloudflare. En raison de nos contrôles d'accès, de nos règles de pare-feu et de l'utilisation de clés de sécurité physiques appliquées via nos propres outils Zero Trust, la capacité de l'acteur malveillant à se déplacer latéralement était limitée. Aucun service n'a été impliqué et aucune modification n'a été apportée à nos systèmes ou à la configuration du réseau mondial. C’est la promesse d’une architecture Zero Trust : c’est comme les cloisons d’un navire où la compromission d’un système ne peut pas compromettre l’ensemble de l’organisation.

Bien que ces informations d'identification aient été considérées comme inutilisables, en fait, autorisé à accéder à la plateforme Atlassian, le système de gestion de code Bitbucket, une application SaaS avec accès administratif à l'environnement Atlassian Jira et un environnement dans AWS qui dessert le répertoire d'applications Cloudflare. Surtout, cet environnement n’a pas accès à l’infrastructure CDN et ne stocke pas de données sensibles.

L'incident n'a pas affecté les données ou les systèmes des utilisateurs de Cloudflare. Un audit a déterminé que l'attaque était limitée aux systèmes exécutant les produits Atlassian et ne s'est pas propagée à d'autres serveurs. Cela est attribué au modèle Zero Trust de Cloudflare et à l'isolement de certaines parties de l'infrastructure, qui ont limité la propagation de l'attaque. Cloudflare mentionne qu'il a également mis en œuvre des règles de pare-feu pour bloquer les adresses IP des attaquants connus et que le cadre d'émulation Sliver Adversary a été supprimé le 24 novembre.

Il est mentionné que le piratage du serveur Cloudflare a été découvert le 23 novembre, mais Les premiers signes d'accès non autorisé au wiki et au système de suivi des problèmes ont été enregistrés le 14 novembre. Le 22 novembre, l'attaquant a installé une porte dérobée pour obtenir un accès permanent, à l'aide de ScriptRunner pour Jira. Le même jour, l’attaquant a également eu accès au système de contrôle, qui utilisait la plateforme Atlassian Bitbucket. Une tentative de connexion au serveur de console utilisé pour accéder à un centre de données au Brésil qui n'était pas encore mis en service a ensuite été tentée, mais toutes les tentatives de connexion ont été refusées.

Apparemment L'activité de l'attaquant s'est limitée à étudier l'architecture du réseau de distribution de contenu et recherchez les points faibles. Utilisation d'une recherche wiki de mots-clés liés à l'accès à distance, aux secrets, à openconnect, à cloudflare et aux jetons.

L'attaquant a accédé à 202 pages wiki (sur 194,100 36) et à 2,059,357 rapports de problèmes (sur 120 11,904 XNUMX) liés à la gestion des vulnérabilités et à la rotation des clés. Le téléchargement de XNUMX référentiels de codes (sur un total de XNUMX XNUMX) a également été détecté, la plupart liés à la sauvegarde, à la configuration et à la gestion des CDN, aux systèmes d'identité, à l'accès à distance et à l'utilisation des plateformes Terraform et Kubernetes. Certains référentiels contenaient des clés chiffrées laissées dans le code, qui ont été remplacées immédiatement après l'incident, malgré l'utilisation de méthodes de chiffrement fiables.

enfin si tu es intéressé à en savoir plus, vous pouvez vérifier les détails dans le lien suivant.


Soyez le premier à commenter

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

*

*

  1. Responsable des données: Miguel Ángel Gatón
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.