Chez Microsoft, un rocambolesque vol de données via une clé trouvée dans un rapport de plantage

Chez Microsoft, un rocambolesque vol de données via une clé trouvée dans un rapport de plantage

Kamoulox

13

Chez Microsoft, un rocambolesque vol de données via une clé trouvée dans un rapport de plantage

En juillet, Microsoft détaillait une campagne malveillante ayant conduit au piratage de 25 victimes, parmi lesquelles des agences gouvernementales américaines. La firme revient avec de nouvelles informations, où l’on apprend que l’opération était de haut vol et a fait le lien entre plusieurs incidents séparés.

Le 11 juillet dernier, Microsoft a publié deux billets de blogs (ici et ). Ils faisaient suite à la découverte d’une opération menée par un groupe malveillant chinois nommé Storm-0558. Au cours de cette campagne, qui a pris place du 15 mai au 16 juin, 25 organisations ont été ciblées avec succès, avec à la clé des vols d’informations. Microsoft ajoutait que, comme pour toute attaque impliquant un acteur malveillant soutenu par un État, les clients touchés avaient été avertis.

La détection de l’attaque a eu lieu le 16 juin. L’entreprise indiquait alors avoir « identifié la cause première, mis en place un suivi durable de la campagne, interrompu les activités malveillantes, renforcé l'environnement, notifié tous les clients concernés et coordonné l'action avec de nombreuses entités gouvernementales ».

Ce que l’on savait en juillet

Selon les informations découvertes il y a quelques mois, il est estimé avec une « assurance modérée » que Storm-0558 est un groupe malveillant chinois à part, malgré quelques recoupements avec d’autres groupes chinois, tels que Violet Typhoon.

Storm-0558 vise prioritairement des personnes ou entités diplomatiques, économiques et législatives, malgré un certain intérêt pour les groupes médias, les think tanks, ainsi que les fournisseurs d’équipements de télécommunications et de services.

Toujours selon Microsoft, le but de ces campagnes est d’obtenir, le plus souvent, des identifiants. Ces derniers sont récupérés via des campagnes de phishing ou des attaques sur des jetons OAuth. L’obtention des identifiants permet ensuite le vol de données.

À chaque fois, Storm-0558 semble avoir de grandes connaissances sur l’infrastructure de la victime, son environnement logiciel, ses politiques de connexions, ses éléments obligatoires d’authentification, ses procédures, etc. Autant d’indices qui classent le groupe dans la catégorie de ceux ayant à la fois les ressources et les compétences nécessaires pour mener à bien des opérations pointues.

Microsoft a pris connaissance de l’attaque le 16 juin, quand l’un de ses clients lui a fait part d’une activité « anormale » sur son compte Exchange Online, sous forme d’anomalies dans les accès aux données. C’est en se basant sur les signaux connus de Storm-0558 que Microsoft lui a attribué l’attaque.

L’accès à Exchange Online s’est fait à travers Outlook Web Access (OWA), et Microsoft a pensé initialement qu’il avait été permis par le vol de jetons Azure Active Directory (AAD). En creusant davantage, l’entreprise a réalisé son erreur. Elle n’a retrouvé en effet que des restes (artefacts) d’authentification à Exchange Online, normalement dérivés des jetons AAD. En outre, une analyse minutieuse de ces artefacts a montré qu’ils ne correspondaient pas à AAD dans les propres journaux de Microsoft.

L’explication était en fait pire : l’attaque avait pu être perpétrée, car Storm-0558 avait la capacité d’émettre ses propres jetons d’authentification. Comment ? Grâce à l’obtention d’une clé de signature provenant d’un compte client Microsoft (MSA). L’utilisation de la clé sur des requêtes qui auraient dû être détectées comme erronées provenait, elle, d’une erreur dans le code de validation. Il s’agissait donc d’une faille de sécurité.

La piste de la clé

Les informations ne s’arrêtent pas là. Une fois que Microsoft a compris comment les pirates avaient réussi leur coup, le modèle utilisé est apparu plus clairement. Partie du principe que des jetons considérés comme authentiques étaient utilisés pour valider des accès qui ne l’étaient pas, la recherche a permis d’identifier d’autres victimes, jusqu’aux 25 connues. Comme indiqué précédemment, toutes ont été prévenues directement.

La question était ensuite de savoir comment Storm-0558 avait réussi à se procurer cette clé. Et l’explication ne manque pas de piquant, comme l'indique Microsoft dans un nouveau billet daté du 6 septembre.

Tout commence en avril 2021 quand un plantage système est notifié chez un client. Comme avec Windows et la plupart des produits professionnels vendus par Microsoft, un vidage mémoire a été effectué, avec création d’un instantané. Ce « crash dump » permet ensuite, après analyse, de comprendre les raisons précises d’un incident.

Lors de sa génération, toutes les informations sensibles sont supprimées. Ou, tout du moins, devraient l’être, car surprise : dans ce rapport, la fameuse clé était présente. Selon Microsoft, une situation de compétition (race condition, en anglais) a permis à la clé d’être présente dans le dump. Ce problème, depuis corrigé, n’a pas non plus été détecté par ses systèmes, situation à laquelle Microsoft a également remédié.

Le fichier de plantage a ensuite été déplacé du réseau isolé de production vers l’environnement de débogage de Microsoft. C’est ici que Storm-0558 entre en piste, car les pirates avaient entre-temps obtenu l’accès au compte d’un ingénieur de la firme. Ce dernier ayant accès à l’environnement de débogage, le groupe chinois a pu passer en revue les crash dumps et trouver ce qui l’intéressait.

Microsoft ajoute qu’à cause de sa politique de rétention des journaux, elle n’a pas de preuve absolue que l’accès a eu lieu de cette manière, mais qu’il s’agit du « mécanisme le plus probable » utilisé par les pirates.

La concordance de ces facteurs pose d’autres questions. On ne sait pas par exemple si les pirates savaient quoi trouver dans le fichier de plantage, ce qui impliquerait qu’ils connaissaient l’existence de la situation de compétition, donc du bug et de son résultat. On ne sait pas non plus s’ils étaient au courant de ce crash dump en particulier, ou s’ils attendaient simplement qu’une occasion se présente. Microsoft ne précise pas depuis combien de temps l’accès via le compte de l’ingénieur était utilisé par Storm-0558.

Les conséquences

Même si les détails de l’attaque de Storm-0558 montrent son niveau de sophistication, les conséquences restent plus importantes. D’abord chez Microsoft, puisque la situation de compétition a été détectée et corrigée, les processus de prévention, de détection et de réponse aux clés erronées ont été renforcés, la détection des clés est plus fine, et les bibliothèques d’authentification concernées ont été mises à jour.

Tout aussi important, la génération des clés MSA a été suspendue immédiatement après et jusqu’au 29, coupant court également à la méthode utilisée par Storm-0558. De nouvelles clés ont été ensuite émises pour les comptes clients.

Cette mesure a été rendue obligatoire par le périmètre des possibilités liées à cette attaque : grâce aux jetons ainsi générés, les pirates étaient en mesure de se faire passer pour n’importe quel compte et d’exploiter ces accès dans toutes les applications hébergées comme Outlook, SharePoint, OneDrive ou encore Teams.

C’est une conséquence de l’approche unifiée du cloud, tous ces services étant basés sur Azure Active Directory pour la gestion des authentifications. Toutefois, puisque les jetons étaient générés à partir d’une clé personnelle, seuls les services acceptant des comptes personnels étaient vulnérables.

Qu’en est-il des victimes ? On ne sait pas exactement quelles sont les conséquences. On sait cependant qu’il s’agissait systématiquement de cibles importantes, comme Gina Raimondo, secrétaire au Commerce des États-Unis, Nicholas Burns, ambassadeur américain en Chine, ou encore Daniel Kritenbrink, secrétaire d’État adjoint pour l’Asie de l’Est. Selon le gouvernement américain, aucune donnée classifiée n’a été dérobée, mais des milliers d’emails ont été volés.

C’est, quoi qu’il en soit et malgré sa transparence, une mauvaise nouvelle pour Microsoft, car cette attaque n’a pu être perpétrée que par l’exploitation d’une série de défaillances techniques dans ses produits.

Notez que sous l’impulsion de la CISA (Cybersecurity & Infrastructure Security Agency) aux États-Unis, Microsoft a accepté d’étendre la période de gratuité pour la disponibilité des données de connexion à son infrastructure, pour permettre aux chercheurs et autres experts en sécurité de détecter des brèches similaires de sécurité à l’avenir.

Commentaires (13)


Rocambolesque, c’est le mot. Merci pour l’article.


Cest surtout hyper sophistiqué plus que Rocambolesque. Le groupe à soit eu un bol monstre de tomber sur le dump avec la clé ou alors ils avaient connaissance du comportement. Clé qui visiblement ne devait pas se trouver là car pas prévu dans ce process de dump. Couplé à la compromission du compte de l’ingénieur.



C’était effectivement une intrusion de haut vol.


C’est vraiment de la chance. Microsoft avait pensé à :




  • faire en sorte que les crash dump soient dans un réseau isolé

  • de nettoyer les informations sensibles des crash dump

  • de double-check avant envoi du dump dans un espace moins sensible
    et tout ça a échoué. Seulement le hacker avait un compte persistant et, en fouillant quasi littéralement les poubelles, il est tombé sur un diamant.
    Je pense que quand ils l’ont récupérés, ils n’ont pas du en croire leurs yeux, et quand ils ont chargés le pfx et vu qu’ils pouvaient effectivement l’exploiter, je ne serais pas étonné qu’un des hackers se soient évanouis tellement c’est énorme.


Merci pour l’article. :love:


Plutôt velue celui-là.
Ça a au moins l’avantage de mettre en avant les risques du “cloud”.


La situation de compétition… le cauchemar. Entre ça et le défaut d’initialisation d’un pointeur, on est dans le top des erreurs indétectables qui peuvent tout bousiller. À elles seules, elles expliquent pourquoi certains devs n’ont plus de cheveux…


En tout cas chapeau aux pirates, on est sur du très haut level, là, hacking de qualité militaire.


Y a du level quand-même là !


Modifié le 07/02/2024 à 15h22

Le compte ingénieur est effectivement un gros point d’ombre. Le plus probable est que son token ait été volé grâce à un malware propagé via phishing ou autre alors que l’ingénieur était connecté…
Concernant les emails, ils veulent dire que si des informations classifiés ont été échangés par email, ce n’est du ressort et de la responsabilité de Microsoft, ce qui est vrai.


article tres interessant. Tres bon niveau des pirates et tres bonne recherche des causes par Microsoft (sont pas mauvais ;)



Toutefois, puisque les jetons étaient générés à partir d’une clé personnelle, seuls les services acceptant des comptes personnels étaient vulnérables.




C’est incorrect : l’article du 6 septembre que vous liez indique que c’est justement parce que la bibliothèque vérifiant le champ de validité de clé ne faisant pas correctement son travail que la clé récupérée dans les informations de débogage (valide pour des comptes d’utilisateurs finaux) ont permis à l’attaquant de générer des jetons pour des courriels d’entreprise :




Developers in the mail system incorrectly assumed libraries performed complete validation and did not add the required issuer/scope validation. Thus, the mail system would accept a request for enterprise email using a security token signed with the consumer key (this issue has been corrected using the updated libraries).




C’est ce pivot qui a permis à l’attaquant d’obtenir des accès pour n’importe quel compte, et ainsi d’infiltrer de la manière la plus normale (en s’authentifiant) dans les infrastructures ciblées, permettant à la fois la reconnaissance et l’attaque, et expliquant pourquoi les infrastructures ciblées étaient si bien connues.


Très intéressant, merci pour cet article.


Fermer