Vol de clé MSA à Microsoft : une série de défaillances rocambolesque

Une série d’erreurs a conduit à l’inclusion accidentelle d’une clé de signature de compte grand public dans un rapport de plantage qui a ensuite été consulté par les acteurs de Storm-0558.

Après plusieurs semaines d’incertitude, Microsoft a confirmé que la clé de signature grand public utilisée pour détourner des comptes de courrier électronique en mai a été dérobée sur son propre réseau. Et pas récemment.

En juillet, Microsoft a révélé qu’un acteur malveillant basé en Chine, suivi sous la référence Storm-0558, a compromis les comptes de courrier électronique de clients au sein d’environ 25 organisations, y compris des agences fédérales américaines. Les assaillants ont utilisé une clé de signature grand public Microsoft Account (MSA) volée pour falsifier des jetons d’authentification pour Outlook Web Access et Outlook.com. Les attaquants ont également exploité un problème de validation de jeton afin de se faire passer pour des utilisateurs d’Azure Active Directory et obtenir un accès à leurs courriels.

Ces attaques ont attiré à Microsoft de vives critiques, notamment à propos de l’information sur la manière dont la clé MSA a été volée, et pour les fonctionnalités de journalisation limitées qui ont entravé la détection des attaques de Storm-0558.

Près de deux mois après avoir révélé les attaques pour la première fois, Microsoft a annoncé mercredi ce que l’enquête a déterminé : la clé a été volée dans son environnement d’entreprise grâce à une série d’erreurs. Storm-0558 a compromis le compte d’un ingénieur de Microsoft et a ensuite obtenu l’accès au réseau de Microsoft et à l’environnement de débogage où la clé MSA se trouvait accidentellement.

La clé MSA s’est retrouvée dans l’environnement de débogage suite à plusieurs erreurs de Microsoft. Au total, Microsoft a identifié six erreurs de sécurité qui ont permis à Storm-0558 d’obtenir un tel accès à un compte à privilèges.

« Suite à notre enquête, nous avons découvert qu’un crash du système de signature client en avril 2021 a entraîné une capture instantanée du processus concerné (“crash dump”). Les captures de crash, qui censurent les informations sensibles, ne devraient pas inclure la clé de signature », a écrit Microsoft sur son blog. « Dans ce cas, une condition de concurrence a permis à la clé d’être présente dans la capture de crash (ce problème a été corrigé). La présence de la clé dans la capture de crash n’a pas été détectée par nos systèmes (ce problème a également été corrigé) ».

Comme Microsoft ne pensait pas que le rapport de plantage contenait des éléments clés, il a été déplacé d’un réseau de production isolé vers l’environnement de débogage de Microsoft, qui était sur le réseau d’entreprise connecté à Internet. Bien que les méthodes de scan du fournisseur n’aient détecté aucune clé de signature, Microsoft a déclaré que l’erreur a été corrigée.

« Après avril 2021, lorsque la clé a été divulguée dans l’environnement d’entreprise via le rapport de plantage, l’acteur référencé Storm-0558 a réussi à compromettre un compte d’entreprise d’un ingénieur de Microsoft », indique l’éditeur.

Mais pourquoi une clé grand public a-t-elle permis d’accéder à des emails d’entreprise ? Microsoft l’attribue à l’introduction d’un « point d’extrémité de publication de métadonnées de clé commune en septembre 2018 » qui était destiné à aider les clients travaillant à la fois avec des applications grand public et d’entreprise.

Une autre erreur de Microsoft a permis au système de messagerie d’accepter une demande de courrier d’entreprise en utilisant un jeton de sécurité signé avec la clé grand public : « dans le cadre d’une bibliothèque de documentation et d’APIs préexistantes, Microsoft a fourni une API pour aider à valider cryptographiquement les signatures mais n’a pas mis à jour ces bibliothèques pour effectuer cette validation de portée automatiquement (ce problème a été corrigé) », peut-on lire.

Pour prévenir ce type d’attaques à l’avenir, Microsoft a déclaré avoir amélioré la détection et la réponse pour les éléments clés inclus par erreur dans les rapports de plantage et a renforcé la recherche d’identifiants afin d’aider à détecter la présence de la clé de signature dans l’environnement de débogage.

Pour approfondir sur Sécurité du Cloud, SASE

Close