La société Cloudflare, qui fournit un réseau de distribution de contenu gérant environ 20 % du trafic Internet, a publié un rapport sur le piratage d'un de ses serveurs, où fonctionnaient un wiki interne basé sur la plateforme Atlassian Confluence, un système de suivi des erreurs Atlassian Jira et un système de gestion de code Bitbucket. L'analyse a révélé que l'attaquant avait pu accéder au serveur en utilisant des tokens obtenus lors du piratage d'Okta en octobre, qui avait conduit à la fuite de tokens d'accès.
Après la divulgation à l'automne des informations sur le piratage d'Okta, Cloudflare a lancé un processus de mise à jour des identifiants, clés et tokens utilisés via les services d'Okta, mais il s'est avéré qu'un token et trois comptes (sur plusieurs milliers) compromis lors du piratage d'Okta n'avaient pas été remplacés et continuaient à fonctionner, ce dont a profité l'attaquant. Les identifiants mentionnés étaient considérés comme inactifs, mais permettaient en réalité d'accéder à la plateforme Atlassian, au système de gestion de code Bitbucket, à une application SaaS ayant un accès administratif à l'environnement Atlassian Jira, ainsi qu'à un environnement AWS desservant le catalogue Cloudflare Apps, mais n'ayant pas accès à l'infrastructure CDN et ne contenant pas de données confidentielles.
L'incident n'a pas touché les données et systèmes des utilisateurs de Cloudflare. Un audit a révélé que l'attaque s'était limitée aux systèmes ayant des produits Atlassian et ne s'était pas étendue à d'autres serveurs, grâce à l'application par Cloudflare d'un modèle de confiance zéro (Zero Trust) et à l'isolation des différentes parties de l'infrastructure.
Le piratage du serveur Cloudflare a été découvert le 23 novembre, et les premières traces d'accès non autorisé au wiki et au système de suivi des erreurs ont été enregistrées le 14 novembre. Le 22 novembre, l'attaquant a installé un backdoor pour obtenir un accès permanent, créé à l'aide de ScriptRunner pour Jira. Ce jour-là, l'attaquant a également eu accès au système de gestion du code source, où la plateforme Atlassian Bitbucket était utilisée. Suite à cela, une tentative de connexion a été entreprise à la console serveur, utilisée pour accéder à un data center encore non opérationnel au Brésil, mais toutes les tentatives de connexion ont échoué.
Apparemment, l'activité de l'attaquant s'est limitée à l'étude de l'architecture du réseau de distribution de contenu et à la recherche de vulnérabilités. Dans le cadre de ses activités, l'attaquant a utilisé une recherche dans wiki avec des mots-clés liés à l'accès à distance, des secrets, openconnect, cloudflared et des jetons. L'ouverture de 202 pages wiki (sur 194100) et de 36 rapports de problèmes (sur 2059357), liés à la gestion des correctifs de sécurité et à la rotation des clés, a été enregistrée. De plus, 120 dépôts de code (sur 11904) ont été téléchargés, la plupart étant liés à la sauvegarde, à la configuration et à la gestion des CDN, aux systèmes d'identification, à l'accès à distance, ainsi qu'à l'utilisation des plateformes Terraform et Kubernetes. Certains de ces dépôts 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.
Source : opennet.ru
