Avertissement : tout ce que Microsoft a certifié est compromis

• Karl Voit estime que le cloud Microsoft Azure a en pratique été piraté et que, faute d’un isolement suffisant, des incidents ultérieurs commencent à être rendus publics
• Il cite comme cas rendu public un article de Reuters selon lequel 60 000 e-mails ont été dérobés sur 10 comptes du département d’État américain
• Son inquiétude centrale est que Microsoft n’a pas réussi à évincer les intrus, ou ne le fait pas, ce qui rend difficile de faire confiance à l’ensemble des systèmes reposant sur l’authentification de Microsoft
• Le périmètre compromis inclut l’authentification Windows et, s’il existe une relation de confiance interne entre des certificats Azure piratés et GitHub, alors GitHub serait lui aussi affecté
• Cela étend l’inquiétude jusqu’aux environnements utilisant NixOS, très dépendants de GitHub, et plus largement au problème du faible contrôle des utilisateurs sur leurs propres données dans le cloud

---

Inquiétudes autour du piratage d’Azure et de l’échec de l’isolement

• Karl Voit affirme que l’ensemble du cloud Azure de Microsoft a, dans les faits, été piraté
• Il précise avoir rassemblé la liste des sources associées dans son texte You Can't Control Your Data in the Cloud
• Selon lui, le cœur du problème n’est pas tant le piratage lui-même que le fait que les mesures d’isolement n’ont pas été suffisantes, si bien que des incidents ultérieurs commencent à être révélés

Cas du vol d’e-mails du département d’État américain

• Comme exemple d’incident ultérieur, il cite un article de Reuters indiquant que 60 000 e-mails ont été volés sur 10 comptes du département d’État américain
• L’article de Reuters lié explique que des hackers chinois ont volé 60 000 e-mails du département d’État américain via le piratage de Microsoft
• Ce cas est présenté comme un élément montrant que des dommages concrets se poursuivent après le piratage de Microsoft

Défiance envers le système d’authentification de Microsoft

• Voit estime que Microsoft n’a pas réussi à expulser les intrus, ou ne les expulse pas
• En conséquence, il considère que tout ce que Microsoft a certifié est tainted, c’est-à-dire compromis
• Il précise que le périmètre compromis inclut aussi l’authentification Windows

Inquiétudes qui s’étendent à GitHub et NixOS

• Dans un texte ultérieur, il affirme que s’il existe une relation de confiance interne chez Microsoft entre des certificats Azure piratés et GitHub, alors GitHub doit lui aussi être considéré comme piraté ou compromis
• Il explique que, même après avoir migré certains hôtes vers NixOS, l’inquiétude persiste à cause des problèmes liés à Microsoft et GitHub
• Il estime que la forte dépendance à GitHub mentionnée dans son article sur son expérience avec NixOS, I Started With Nix, NixOS, Home Manager and Flakes, apparaît comme un défaut majeur de cet OS

Problème du contrôle des données dans le cloud

• Le texte lié You Can't Control Your Data in the Cloud élargit les problèmes d’Azure et de l’authentification Microsoft à la question du contrôle des données dans le cloud
• L’avertissement publié sur Mastodon insiste sur la difficulté à faire confiance à l’ensemble des systèmes reposant sur l’authentification de Microsoft et sur des relations de confiance internes

[GN⁺]

Avis sur Hacker News

• Si l’on regarde les sections « atténuation » et « renforcement » du billet de Microsoft sur l’incident, il y est indiqué que le 26 juin, OWA a cessé d’accepter les renouvellements de tokens émis par GetAccessTokensForResource, que le 27 juin, OWA a bloqué l’utilisation de tokens signés avec la clé MSA volée, et que le 29 juin, la rotation des clés ainsi que la révocation des clés de signature MSA alors valides avaient été achevées.
  Le 3 juillet, ils disent aussi avoir bloqué l’utilisation de cette clé pour tous les clients grand public affectés, afin d’empêcher l’exploitation de tokens déjà émis.
  Je ne suis pas spécialiste de la sécurité, mais je me demande quel est le trou dans cette stratégie.

  • Le problème, c’est qu’il n’existe aucun moyen de vérifier ce que l’attaquant a fait avec la clé volée entre-temps.
    Avec des journaux d’audit permanents et immuables, on pourrait retracer toutes les actions effectuées via des authentifications signées directement ou indirectement par la clé divulguée, mais créer des journaux d’audit que même une personne disposant des privilèges les plus élevés ne peut pas manipuler n’est ni facile ni bon marché.
    Dans le pire des cas, les journaux d’audit ne contiennent que l’identité authentifiée, sans le mode d’authentification, ce qui peut empêcher d’identifier facilement les accès potentiellement compromis.
    Au final, le trou dans cette stratégie est qu’elle ne tient pas compte des backdoors persistantes qui auraient pu être ajoutées pendant la période où la clé divulguée permettait l’accès. Elle bloque les exploitations ultérieures, mais vu la manière dont la clé a été volée, si l’attaquant était très sophistiqué, il est quasiment impossible de savoir combien de chemins d’accès secondaires il a mis en place.
  • Le gros problème, c’est qu’il n’y a aucun moyen de savoir quels autres trous ou backdoors l’attaquant a introduits pendant qu’il disposait de ces identifiants. Il a même pu faire en sorte d’obtenir immédiatement les nouvelles clés.
  • Ces points semblent plutôt contredire le titre selon lequel « la clé a été compromise et est encore utilisée » ou que « tout est contaminé ».

• Ce problème semble limité à Azure et Microsoft ; AWS et GCP me paraissent corrects.
  Microsoft a parmi les pires vulnérabilités et pratiques de sécurité que j’aie vues. Je n’arrive vraiment pas à comprendre comment des dirigeants de grandes entreprises du Fortune 500 peuvent déplacer leurs workloads vers Azure.
  Dans certains domaines, le seul argument de vente d’Azure est qu’Amazon est un concurrent. Ce serait bien qu’Amazon laisse simplement AWS être une entité indépendante.
  J’aimerais que Microsoft relève son niveau de sécurité, mais à ce stade, cela paraît presque sans espoir.

  • Microsoft attire les entreprises non techniques avec Active Directory et Office 365, puis les retient en promettant une bonne intégration avec tous ses services.
    Une fois que les entreprises sont dans le tableau de bord Azure, le système les pousse à essayer aussi les services qui y sont proposés et qui ont l’air séduisants.
    Tout cela ressemble à de la poudre aux yeux, mais ça fonctionne.
  • Presque toutes les organisations ont déjà d’énormes contrats avec Microsoft autour de Windows, AD, Office, Teams, Exchange, etc., et Microsoft est profondément intégré à leur IT de base.
    Donc si l’organisation n’a pas déjà enregistré AWS comme fournisseur, il est généralement plus facile de pousser le fournisseur existant.
  • Les CTO et les administrateurs système ont aussi leur part de responsabilité. Soit ils sont prisonniers de cette stack par habitude, soit le CTO a imposé le choix en mode « personne n’a jamais été viré pour avoir choisi une option dans le quadrant supérieur droit de Gartner ».
  • En 1996-1997, lorsque je travaillais comme sous-traitant fédéral pour l’armée américaine, nous avions remplacé des serveurs web Windows par des serveurs Macintosh parce qu’ils étaient plus sûrs.
    Moi aussi, j’exploitais un serveur web sous Windows 2000 Pro avant de passer à Linux à cause du manque de sécurité.
    Microsoft peut être populaire, mais sa sécurité a de gros trous, et cela a toujours été le cas.
  • « Ce problème », oui.
    Les services sont souvent compromis, qu’ils soient dans le cloud ou gérés par les clients. Microsoft dispose d’une équipe sécurité mature, professionnelle et efficace.
    La compromission est due à des défauts d’implémentation et, à titre de supposition personnelle, à un ou plusieurs initiés corrompus.
    La plupart des organisations n’auraient probablement même pas su ce qui se passait, et n’auraient pas été capables d’identifier les éléments rendus publics.
    Avec le recul, tout paraît toujours facile.

• C’est une formulation beaucoup trop exagérée. C’était clairement une compromission grave, et il est possible que l’on n’en comprenne pas encore entièrement la portée, mais dans « ils auraient pu placer partout des backdoors et leurs propres clés », le point essentiel est auraient pu : autrement dit, « à ma connaissance, c’est théoriquement possible », pas qu’ils l’aient réellement fait.
  La conclusion selon laquelle « tout chez Microsoft a été hacké, et ils ne peuvent pas ou ne veulent pas expulser les intrus. Tout ce que Microsoft certifie est contaminé, y compris la certification Windows » est elle aussi excessive.
  La réponse de Microsoft semble dire clairement qu’ils ont remplacé les clés et les ont déplacées vers un stockage plus sûr. Ils ne disent pas avoir expulsé l’attaquant, mais ils ne disent pas non plus que l’attaque est toujours en cours. Cela ne signifie pas non plus que toute authentification est définitivement cassée.
  Les conclusions tirées me semblent extrêmes.
  https://msrc.microsoft.com/blog/2023/09/results-of-major-tec...

  • Le rapport d’enquête de Microsoft sur l’exploit est cité en lien : l’attaquant a d’abord accédé au réseau de développement de Microsoft, a trouvé un crash dump, en a compris la portée, l’a fouillé pour trouver une clé privée, puis a suffisamment compris le système d’authentification de Microsoft pour savoir comment utiliser cette clé au-delà de son objectif initial, et l’a fait.
    Et malgré cela, on est censé croire qu’il n’a pas laissé de backdoor persistante sur des cibles de premier plan ?
    La conclusion tirée ici est tout à fait raisonnable. Pour les clients ordinaires du cloud public, l’argument peut éventuellement se tenir : des backdoors indiscriminées ne feraient qu’augmenter le risque d’être découvert.
    Mais les grandes entreprises et les utilisateurs gouvernementaux doivent partir du principe qu’il y a eu compromission ; sinon, ce serait d’une naïveté difficile à croire.
    Référence :
    https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
    Microsoft écrit aussi que Storm-0558 dispose d’un haut niveau de capacité opérationnelle technique et de sécurité opérationnelle, et connaît bien les environnements ciblés, les politiques de journalisation, les exigences d’authentification, ainsi que les politiques et procédures.
  • Du point de vue de la sécurité, compte tenu de l’impact potentiel et des scénarios possibles, on ne peut pas simplement considérer cela comme « possible » ; il faut supposer que c’est réel.
    Quand on découvre une vulnérabilité zero-day, on n’ignore pas le correctif en se disant que « les autres ne l’ont probablement pas ».
  • Je pense que Microsoft recevra toutes les ressources nécessaires, y compris l’aide d’agences fédérales, pour supprimer les binaires implantés et les mauvaises configurations.

• Cette affaire a été beaucoup trop peu couverte, et son impact potentiel pourrait être énorme. Ce que je reproche à Microsoft, c’est ceci : la clé a fuité en 2021 et signait encore des jetons d’authentification en 2023, alors qu’aucun service Azure ne permet aux utilisateurs de fournir des identifiants valables deux ans.
  C’est le cas typique du « fais ce que je dis, pas ce que je fais ».

  • Il suffit d’imaginer ce que ferait le CA/Browser Forum s’il apprenait qu’une CA PKIX avait perdu le contrôle de sa clé de signature, ne l’avait pas révoquée, n’avait prévenu personne, et avait continué à l’utiliser pendant deux ans.
  • Si j’ai bien compris, ils n’utilisaient même pas de HSM, et leur plan d’atténuation n’incluait pas non plus l’usage d’un HSM. Ce n’est pas acceptable.
  • Le pire dans cette histoire, c’est que ces clés n’étaient même pas les bonnes clés au départ. Il s’agissait de clés émises pour certains clients et dont la portée était limitée, mais la vérification de portée était cassée. Globalement, c’est mauvais à un point difficile à croire.
  • Il est toujours possible de créer des app registration secrets qui durent jusqu’à deux ans. Jusqu’à récemment, on pouvait même créer des secrets pratiquement sans date d’expiration.

• Cela me semble très exagéré et alarmiste. Je ne pense pas que les sources prouvent l’ampleur de la compromission avancée dans l’article, à savoir « tout Microsoft »
  Cela ressemble plutôt à un cas de fuite de clé temporaire, ensuite révoquée

  • En suivant les liens de l’article, on trouve qu’en juillet 2023, des hackers ont volé un certificat Microsoft Azure Active Directory, ce qui leur aurait donné un accès complet à pratiquement tous les services cloud de Microsoft, dont Outlook, Office, SharePoint, Teams, « Login with Microsoft », etc.
    Il y a aussi ceci :
    https://infosec.exchange/@briankrebs/110820474957163710
    Si c’est vrai, c’est extrêmement grave.
    [1] : https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
    [2] : https://www.wiz.io/blog/storm-0558-compromised-microsoft-key...
  • Un meilleur lien aurait sans doute été cette page, liée dans l’article :
    https://karl-voit.at/cloud/
    Dans cette longue liste, il est aussi indiqué qu’en août 2023, Azure a connu un problème d’« accès non autorisé à des applications inter-locataires et à des données sensibles, y compris des secrets d’authentification », que Microsoft n’a pas réussi à corriger pendant plusieurs mois, et qu’au 03/08/2023 il s’agissait encore d’une vulnérabilité publique d’Azure.
    Pour l’incident de juillet 2023, il est dit que les clients ne pouvaient même pas détecter les intrus avec les journaux de base, et qu’il fallait payer un supplément pour accéder aux fichiers de logs concernés.
    Microsoft n’a pas indiqué quels services étaient touchés ou non, et le résumé revient à dire qu’il faut considérer que tous les services cloud de Microsoft ont potentiellement été compromis.
    Il est également indiqué que des experts en sécurité comme Mike Kuketz estiment qu’il faut considérer comme compromis tous les systèmes Microsoft utilisant l’authentification cloud, jusqu’aux hôtes Windows.
  • Sur certains services, même Microsoft n’a pas le contrôle des données. C’est le cas de KV ou de MHSM.
    L’article de Microsoft dans le même lien dit aussi ceci :
    https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
    « Activité post-compromission : d’après notre télémétrie et notre enquête, l’activité post-compromission s’est limitée à l’accès aux e-mails et à leur exfiltration pour les utilisateurs ciblés »
    Donc ce n’est pas « tout Microsoft ». C’est un titre exagéré assez classique, qui a simplement attiré l’attention cette fois via un post Mastodon.
    Cette plateforme n’est pas très différente de Twitter.

• Dans quelques années, je pense que le matériel on-premise et l’hébergement de serveurs simple redeviendront à la mode

  • La centralisation et la cloudification récentes d’Internet et de l’électronique sont assez ironiques.
    Quand tout était local et privé, la sécurité était souvent faible, mais un attaquant ne pouvait accéder qu’à un appareil ou à un réseau précis.
    Désormais, les gains potentiels lorsqu’on attaque une organisation centralisée sont tellement importants que les attaquants ont intérêt à mobiliser beaucoup plus de ressources.
  • Mais le cloud est beaucoup plus sûr. Qui pourrait bien pirater tout le cloud Microsoft ? Ah, attendez…
  • Le point clé, c’est la « simplicité ». Pour certaines applis, je me suis demandé pourquoi on les avait mises dans le cloud au départ.
    Tous les mois ou deux, il fallait migrer vers une nouvelle version d’environnement stupide, modifier des entrées DNS parce que l’appli n’arrivait pas à envoyer d’e-mails, configurer l’IAM médiocre d’un fournisseur cloud dont on n’avait pas besoin, et enregistrer l’appli pour accéder à la base de données.
    Aujourd’hui, il existe des applis qui demandent 15 minutes de maintenance par an, et 5 minutes d’installation et de configuration.
    Certains fournisseurs cloud ont des fonctionnalités impressionnantes, mais tout donne de plus en plus l’impression de devenir bloaté, et je n’ai pas besoin d’un cluster complet pour mon cas d’usage.
  • C’est déjà en train de commencer. Je conçois un système dans un pays européen, et les collectivités locales comme les administrations régionales demandent davantage de configurations on-premise.
    J’ai aussi entendu parler de plusieurs projets visant à créer davantage de services cloud européens.
  • Le matériel on-premise peut redevenir tendance, mais l’hébergement de serveurs simple a peu de chances de suivre.
    Si cela revient à la mode, ce sera probablement sous la forme de conteneurs ou d’un orchestrateur Kata Containers posé sur du matériel on-premise.
    Et même avec des logiciels déployés on-premise, les grandes organisations auront toujours besoin de single sign-on, et pourront donc rester exposées à ce type d’attaque.

• C’est vraiment grave. Grâce à cet article, je suis enfin en train de lire le sujet correctement, et je ne comprends pas comment cela a pu passer autant sous les radars.
  L’entreprise où je travaille a récemment unifié toute l’authentification de ses applis et services internes via Azure. Avec le recul, j’ai l’impression que c’était une erreur, même si je suis peut-être trop parano.

  • Je ne comprends pas comment cela a pu rester aussi peu médiatisé.
    Peu avant cette affaire, il y avait déjà eu un « incident » où n’importe qui pouvait modifier certains résultats de recherche Bing, et probablement aussi d’autres services.
    En conséquence, il était possible d’accéder à toutes les données que le navigateur partage avec Bing, ce qui incluait aussi toutes les clés d’accès des comptes MS des utilisateurs qui utilisaient Bing pour cette recherche précise.
    L’impact est inconnu, car Microsoft ne l’a pas rendu public. Chacun peut imaginer pourquoi.
  • Cette analyse post-mortem était déjà en une il y a quelques semaines. Pas besoin d’aller jusqu’à la théorie du complot : c’est simplement de la mauvaise gestion ordinaire de la Big Tech.

• Le texte est excellent, effrayant, et semble ne contenir que des informations vraies et vérifiables, mais je ne sais pas très bien à quoi il faudrait s’attendre
  Les gens « ordinaires » ne liront pas ça, ne le comprendront pas et ne pourront pas en mesurer l’impact. C’est devenu trop complexe. Socialement, on ne peut pas non plus simplement arrêter d’utiliser les services mentionnés
  Je me demande s’il ne serait pas plus rationnel d’enseigner plutôt ceci : il n’y a pas de vie privée, elle ne peut pas être garantie et personne n’a d’incitation à la garantir ; il n’y a pas de sécurité, toute sécurité a été compromise, est conçue pour l’être ou le sera à l’avenir ; toute information numérique est déjà publique ou le sera un jour

  • Je ne suis pas d’accord avec l’idée que les gens « ordinaires » ne comprennent pas
    Pas besoin de dix ans d’expérience en IT pour comprendre que « Microsoft a permis à un client d’ouvrir les coffres de tous les bureaux avec la clé de sa propre maison, l’a caché pendant deux ans, et n’a toujours pas de plan pour corriger le problème »
    McNeally avait tout simplement tort. Mais le désespoir est plus facile que la réparation, donc beaucoup de gens ont choisi le désespoir, et la popularité du cloud et du SaaS en est le résultat
    Ce n’est pas une fatalité : il suffit de ne pas faire confiance à des gens auxquels on ne fait pas réellement confiance
  • Ces trois points n’enseignent que le désespoir. Ce qui serait plus utile, c’est d’enseigner à qui demander des comptes, et comment récupérer une vraie vie privée et sécurité
    Même s’il faut pour cela utiliser le redouté marteau réglementaire
  • C’est le genre de point de vue qu’on attendrait d’organisations qui poussent à la transparence totale, par exemple l’industrie publicitaire ou la sécurité nationale, ou de personnes endoctrinées par elles. Il n’est pas encore nécessaire d’aller jusqu’à ce désespoir
    On peut encore avoir une vie privée garantie. Par exemple, en allant en forêt sans appareil
    L’incitation à garantir la vie privée d’autrui peut être un dispositif juridique : une sanction en cas d’échec
    La sécurité absolue n’existe pas, mais il existe une sécurité face à certains modèles de menace
    J’ai aussi du mal à comprendre pourquoi des données stockées sur un appareil non connecté au réseau devraient forcément devenir publiques
  • Il est normal d’attendre des personnes et des entreprises qu’elles corrigent les problèmes lorsqu’ils apparaissent
    Même en passant sur l’expression « gens ordinaires », je ne vois pas pourquoi on ne pourrait pas vivre sans des services qui ne sont même pas cités, ou les remplacer par des options plus respectueuses de la vie privée
    L’enseignement le plus rationnel serait que la vie privée est essentielle à une société et à une économie fonctionnelles. Quiconque dit le contraire estime pouvoir gagner de l’argent à court terme en exploitant l’asymétrie d’information entre vous et lui
    Je respecte Scott, mais cette déclaration n’était pas l’un de ses meilleurs moments. On pourrait remplacer la même phrase par « il n’y a pas de propriété, elle ne peut pas être garantie, et personne n’a d’incitation à la garantir » et cela pourrait sembler parfaitement vrai ; pourtant, nous avons bel et bien créé des moyens de garantir la propriété, à savoir le droit et un gouvernement chargé de l’appliquer. On peut appliquer ce concept éprouvé à la vie privée
    Toutes les serrures peuvent être ouvertes, mais tout le monde ne sait pas crocheter une serrure ; c’est pourquoi nous continuons à fermer nos portes à clé
    Je doute aussi que les plus grands cabinets de conseil partent du principe que toute information numérique devient publique. Les cabinets de ce genre décrits dans « The Big Con » de Mazzucato et Collington peuvent vendre cette prémisse, mais ils ne fonctionnent pas réellement ainsi
    Par exemple, si McKinsey avait su que ses conseils à Purdue Pharma deviendraient publics, l’entreprise n’aurait pas perdu autant
    En résumé, quelqu’un qui dit que la vie privée n’a pas d’importance dit en réalité que votre vie privée n’a pas d’importance, tout en étant trop sûr de pouvoir rester lui-même du bon côté de l’asymétrie d’information et préserver sa confidentialité. Les efforts de Google pour garder ses propres informations confidentielles lors d’un procès antitrust public l’illustrent ironiquement
  • C’est un très mauvais conseil, et s’il vient de quelqu’un du secteur, il peut aussi être intéressé. Comme toujours, il y a des nuances. C’est du genre « seuls les Sith raisonnent en absolus »
    En ligne, il n’y a pas de vie privée, et les fournisseurs ont intérêt à vendre leurs utilisateurs. Il faut donc se défendre en ne conservant qu’une présence en ligne superficielle
    Pour un utilisateur ordinaire, il faut publier le moins d’informations possible, surtout sur les réseaux sociaux. Si une présence en ligne est nécessaire, il faut évaluer les risques et consacrer du temps et de l’argent à les réduire. Si cet effort de mitigation ne montre pas de retour sur investissement, il y a de bonnes chances qu’on vous ait fait croire à tort que cette présence en ligne était nécessaire
    La sécurité absolue n’existe pas. Toutes les défenses peuvent être contournées, mais elles ne le sont pas nécessairement. Il suffit d’évaluer autant de risques que possible, et de ne réduire que ceux pour lesquels on anticipe un retour sur investissement positif. Les risques non mitigés doivent être acceptés, et ceux qu’on ne peut pas se permettre d’assumer doivent être évités en refusant tout simplement d’utiliser le système
    Même sans aucune gestion des risques, il existe un niveau de sécurité de base, parce qu’une partie de la population portée vers la criminalité calcule coûts et bénéfices. Plus les cyniques qui connaissent les coulisses répètent qu’il n’y a pas de sécurité, plus cette base se rapproche de zéro, et plus le grand public devient vulnérable
    Plus cette base baisse, plus les individus doivent investir eux-mêmes du temps et de l’argent pour atteindre un niveau de sécurité supportable. Le cynisme nous coûte cher : autrement dit, ne pissez pas et ne chiez pas dans le moulin du village juste parce que ça a l’air cool
    Les informations numériques actuelles sont déjà publiques ou peuvent le devenir un jour. Mais on peut choisir des technologies qui repoussent ce moment plus loin dans le futur, et pour les informations qui ne sont pas encore numérisées, décider consciemment si le confort justifie le risque

• Dire que « des experts en sécurité comme Mike Kuketz considèrent que tous les systèmes Microsoft utilisant l’authentification cloud, jusqu’aux hôtes Windows, doivent être considérés comme compromis » est une affirmation énorme
  Il semble théoriquement possible que la clé de signature volée ait été utilisée dans le cadre d’une attaque plus vaste donnant accès à des services critiques comme Windows Update ou le plan de contrôle Azure
  Mais s’il y avait eu une telle compromission systémique, quelqu’un s’en serait aperçu, je pense

  • Quelqu’un aurait aussi dû remarquer l’utilisation illégale de la clé volée pendant deux ans… ah, oui

• Le billet d’origine et le blog sont bien mieux illustrés par l’explication de Microsoft : https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
  Par ailleurs, contrairement à ce qui est affirmé ici, Microsoft a corrigé le problème après en avoir eu connaissance : https://msrc.microsoft.com/blog/2023/09/results-of-major-tec...

  • Trop tard. Les dégâts étaient déjà faits. Quiconque possédait cette clé aurait pu accéder à tous les comptes et services MS
    Et ces personnes avaient déjà piraté des comptes d’ingénieurs. La probabilité de tomber par hasard sur cette clé en ne piratant qu’un seul compte d’ingénieur est très faible ; il est donc raisonnable de penser que plusieurs comptes d’ingénieurs de Microsoft avaient déjà été compromis
    En gros, les comptes MS ne sont pas sûrs