Microsoft a révélé mercredi la cause d’une brèche dans son service cloud Azure qui a permis à des pirates informatiques de compromettre des dizaines de comptes Azure et Exchange appartenant à des utilisateurs de haut niveau. Selon la société, le compte d’entreprise d’un de ses ingénieurs a été piraté par un acteur malveillant très compétent qui a obtenu une clef de signature utilisée pour falsifier des jetons pour le service Azure AD.La brèche avait été annoncée par Microsoft en juillet, mais la société n’avait pas expliqué comment les pirates informatiques, suivis sous le nom de Storm-0558, avaient réussi à accéder à son réseau interne pendant plus d’un mois et à s’emparer de la clef de signature. Cette clef, normalement expirée, leur a permis de se faire passer pour des utilisateurs légitimes d’Azure, un service cloud qui héberge des applications et des données sensibles.
Microsoft a déclaré que la clef de signature volée était une clef de consommateur Microsoft qui n’était confiée qu’à des employés ayant subi une vérification des antécédents et travaillant sur des postes de travail dédiés protégés par une authentification à plusieurs facteurs utilisant des dispositifs de jetons matériels. Pour protéger cet environnement dédié, les outils de messagerie, de conférence, de recherche web et autres outils de collaboration n’étaient pas autorisés, car ils constituent les vecteurs les plus courants d’attaques réussies par logiciels malveillants et phishing.
Cependant, ces mesures de sécurité ont été contournées en avril 2021, plus de deux ans avant que Storm-0558 ne pénètre dans le réseau de Microsoft. L'entreprise donne des détails de la situation :
Envoyé par Microsoft
Notre enquête a révélé qu'un crash du système de signature des consommateurs en avril 2021 a donné lieu à un snapshot du processus bloqué (« crash dump »). Les dumps sur incident (crash dump), qui suppriment les informations sensibles, ne doivent pas inclure la clef de signature. Dans ce cas, une condition de concurrence critique permettait à la clef d'être présente dans crash dump (ce problème a été corrigé). La présence du matériel clef dans le crash dump n’a pas été détectée par nos systèmes (ce problème a été corrigé).
Nous avons constaté que ce crash dump, censé à l'époque ne contenir aucun élément clef, avait ensuite été déplacé du réseau de production isolé vers notre environnement de débogage sur le réseau d'entreprise connecté à Internet. Ceci est cohérent avec nos processus de débogage standard. Nos méthodes d'analyse des informations d'identification n'ont pas détecté sa présence (ce problème a été corrigé).
Après avril 2021, lorsque la clef a été divulguée dans l’environnement de l’entreprise lors du crash dump, l’acteur de Storm-0558 a réussi à compromettre le compte d’entreprise d’un ingénieur Microsoft. Ce compte avait accès à l'environnement de débogage contenant le crash dump qui contenait de manière incorrecte la clef. En raison des politiques de conservation des journaux, nous ne disposons pas de journaux contenant des preuves spécifiques de cette exfiltration par cet acteur, mais il s’agit du mécanisme le plus probable par lequel l’acteur a acquis la clef.
Nous avons constaté que ce crash dump, censé à l'époque ne contenir aucun élément clef, avait ensuite été déplacé du réseau de production isolé vers notre environnement de débogage sur le réseau d'entreprise connecté à Internet. Ceci est cohérent avec nos processus de débogage standard. Nos méthodes d'analyse des informations d'identification n'ont pas détecté sa présence (ce problème a été corrigé).
Après avril 2021, lorsque la clef a été divulguée dans l’environnement de l’entreprise lors du crash dump, l’acteur de Storm-0558 a réussi à compromettre le compte d’entreprise d’un ingénieur Microsoft. Ce compte avait accès à l'environnement de débogage contenant le crash dump qui contenait de manière incorrecte la clef. En raison des politiques de conservation des journaux, nous ne disposons pas de journaux contenant des preuves spécifiques de cette exfiltration par cet acteur, mais il s’agit du mécanisme le plus probable par lequel l’acteur a acquis la clef.
Pourquoi une clef client a pu accéder à la messagerie d'entreprise
Répondant au deuxième mystère, Microsoft explique comment une clef de signature expirée pour un compte consommateur a été utilisée pour forger des jetons pour des offres d'entreprise sensibles. En 2018, Microsoft a introduit un nouveau framework fonctionnant avec les applications cloud grand public et d'entreprise. Des erreurs humaines ont empêché une interface de programmation conçue pour valider cryptographiquement l’environnement pour lequel une clef devait être utilisée, de fonctionner correctement.
Pour répondre à la demande croissante des clients en matière de prise en charge d'applications fonctionnant à la fois avec des applications grand public et d'entreprise, Microsoft a introduit un point de terminaison de publication de métadonnées clefs communes en septembre 2018. Dans le cadre de cette offre convergée, Microsoft a mis à jour la documentation pour clarifier les exigences en matière de validation de la portée clef - quelle clef à utiliser pour les comptes d'entreprise et lesquels à utiliser pour les comptes de particuliers.
Dans le cadre d'une bibliothèque préexistante de documentation et d'API d'assistance, Microsoft a fourni une API pour aider à valider les signatures de manière cryptographique, mais n'a pas mis à jour ces bibliothèques pour effectuer automatiquement cette validation de portée (ce problème a été corrigé). Les systèmes de messagerie ont été mis à jour pour utiliser le point de terminaison de métadonnées commun en 2022. Les développeurs du système de messagerie ont supposé à tort que les bibliothèques effectuaient une validation complète et n'ont pas ajouté la validation d'émetteur/portée requise. Ainsi, le système de messagerie accepterait une demande de courrier électronique d'entreprise utilisant un jeton de sécurité signé avec la clef du consommateur (ce problème a été corrigé à l'aide des bibliothèques mises à jour).
Dans le cadre d'une bibliothèque préexistante de documentation et d'API d'assistance, Microsoft a fourni une API pour aider à valider les signatures de manière cryptographique, mais n'a pas mis à jour ces bibliothèques pour effectuer automatiquement cette validation de portée (ce problème a été corrigé). Les systèmes de messagerie ont été mis à jour pour utiliser le point de terminaison de métadonnées commun en 2022. Les développeurs du système de messagerie ont supposé à tort que les bibliothèques effectuaient une validation complète et n'ont pas ajouté la validation d'émetteur/portée requise. Ainsi, le système de messagerie accepterait une demande de courrier électronique d'entreprise utilisant un jeton de sécurité signé avec la clef du consommateur (ce problème a été corrigé à l'aide des bibliothèques mises à jour).
À ces questions s’ajoutent les suivantes : une clef aussi sensible que celle acquise par Storm-0558 n’était-elle pas stockée dans un HSM (module matériel de sécurité) ? Il s'agit d'appareils dédiés qui stockent des informations importantes et sont conçus pour empêcher l'acquisition de clef de formulaire divulguée par Microsoft.
Le représentant a également déclaré que « les systèmes d’identité de l’entreprise gèrent les clefs en utilisant une combinaison de protections HSM et logicielles en raison des exigences uniques d’échelle et de résilience de l’environnement cloud ». Cela n’explique toujours pas comment les attaquants ont réussi à extraire la clef d’un appareil spécialement conçu pour empêcher le vol.
La nécessité de renforcer une posture de sécurité
La brèche dans Azure AD a eu des conséquences importantes pour les utilisateurs de Microsoft, car elle a permis aux pirates informatiques de se connecter à des comptes Azure et Exchange sans avoir besoin de mots de passe ou d’autres informations d’identification. Les pirates informatiques ont également pu modifier les paramètres de sécurité des comptes, tels que les règles de transfert de courrier électronique, les stratégies d’accès conditionnel et les règles de flux de messagerie. Ces modifications ont rendu plus difficiles la détection et l’élimination des pirates informatiques des systèmes compromis.
Microsoft a déclaré qu’il avait informé les clients affectés par la brèche et qu’il leur avait fourni des outils et des conseils pour restaurer la sécurité de leurs comptes. La société a également recommandé aux utilisateurs d’Azure AD de passer à l’authentification multifacteur (MFA) et à la protection contre les menaces basées sur le cloud, qui peuvent réduire le risque d’attaques par falsification de jetons.
En juillet, Microsoft déclarait :
Microsoft a atténué une attaque menée par un acteur malveillant basé en Chine que Microsoft appelle Storm-0558 et qui ciblait les e-mails des clients. Storm-0558 cible principalement les agences gouvernementales d'Europe occidentale et se concentre sur l'espionnage, le vol de données et l'accès aux informations d'identification. Sur la base des informations signalées par les clients le 16 juin 2023, Microsoft a ouvert une enquête sur une activité de messagerie anormale. Au cours des semaines suivantes, notre enquête a révélé qu'à partir du 15 mai 2023, Storm-0558 a eu accès à des comptes de messagerie affectant environ 25 organisations dans le cloud public, y compris des agences gouvernementales, ainsi qu'à des comptes de consommateurs associés d'individus probablement associés à ces organisations. Pour ce faire, ils ont utilisé de faux jetons d'authentification pour accéder au courrier électronique des utilisateurs à l'aide d'une clef de signature de consommateur de compte Microsoft (MSA) acquise. Microsoft a terminé l'atténuation de cette attaque pour tous les clients.
Sources : Microsoft (1, 2)
Et vous ?
Que pensez-vous de la réaction de Microsoft face à la brèche dans Azure AD ? A-t-elle été suffisamment transparente et proactive ? Quelles sont les mesures que vous prenez pour protéger vos comptes et vos données sur le cloud ? Utilisez-vous l’authentification multifacteur et la protection contre les menaces basée sur le cloud ? Quels sont les risques et les avantages de confier vos applications et vos données sensibles à un service cloud comme Azure ? Préférez-vous utiliser un service cloud public, privé ou hybride ? Comment évaluez-vous le niveau de compétence et de motivation des pirates informatiques qui ont réussi à pénétrer dans le réseau interne de Microsoft ? Pensez-vous qu’ils soient liés à un groupe ou à un pays particulier ? Quelles sont les conséquences potentielles de la brèche dans Azure AD pour les utilisateurs de Microsoft et pour l’industrie du cloud en général ? Comment peut-on prévenir ou atténuer de telles attaques à l’avenir ? 
