- Résultats de l’enquête technique sur l’incident au cours duquel l’acteur malveillant basé en Chine Storm-0558 a falsifié des jetons à l’aide d’une clé de signature MSA grand public dérobée pour accéder à OWA et Outlook.com
- Un crash du système de signature grand public en avril 2021 a généré un crash dump contenant la clé en raison d’une condition de concurrence (race condition), sans que le système ne la détecte
- Le crash dump contenant la clé a été déplacé depuis un réseau de production isolé vers un environnement de débogage sur le réseau d’entreprise connecté à Internet, sans être détecté non plus par l’analyse des identifiants
- Si une clé grand public pouvait permettre d’accéder à des emails d’entreprise, c’est parce que les développeurs du système de messagerie ont supposé à tort que la bibliothèque vérifiait bien le scope, et n’ont pas ajouté de validation de l’issuer/du scope
- Toutes les défaillances ont été corrigées, et des mesures post-incident comme le renforcement automatisé de la validation du scope des clés ont été mises en place dans une défense multicouche
Circonstances de l’acquisition de la clé
- Microsoft exploite un environnement de production isolé et restreint, avec vérification des antécédents, comptes dédiés, postes de travail sécurisés pour les accès sensibles et authentification multifacteur basée sur des jetons matériels
- Cet environnement bloque l’usage des outils de collaboration tels que l’email, les réunions et la recherche web, afin d’éviter les vecteurs de compromission de comptes comme les infections par malware ou le phishing
- Les politiques Just in Time / Just Enough Access limitent l’accès aux systèmes et aux données
- L’environnement d’entreprise (corporate environment) exige des certifications et des équipements de sécurité, mais autorise l’usage de l’email, des réunions et des outils collaboratifs, ce qui l’expose davantage au spear phishing et aux malwares voleurs de jetons
- Conformément aux principes Zero Trust et d’"assume breach", les matériels de clé ne doivent pas quitter l’environnement de production
- En avril 2021, un crash du système de signature grand public a généré un crash dump (instantané du processus planté)
- Un crash dump est censé masquer les informations sensibles et ne devrait donc pas contenir de clé de signature, mais une condition de concurrence a entraîné sa présence (corrigé depuis)
- Le système n’a pas détecté la présence de la clé dans le crash dump (corrigé depuis)
- Un crash dump alors considéré comme ne contenant pas de clé a été déplacé du réseau de production isolé vers un environnement de débogage
- Cela était conforme aux procédures standard de débogage, et l’analyse des identifiants n’a pas détecté la présence de la clé (corrigé depuis)
- Après la fuite de la clé, l’acteur Storm-0558 a compromis le compte d’entreprise d’un ingénieur Microsoft
- Ce compte disposait d’un accès à l’environnement de débogage où se trouvait le crash dump contenant la clé
- En raison de la politique de conservation des logs, il n’existe pas de journaux prouvant précisément l’exfiltration, mais cela reste la piste la plus probable pour l’acquisition de la clé
Pourquoi une clé grand public pouvait permettre l’accès aux emails d’entreprise
- Pour répondre à la demande des clients souhaitant prendre en charge à la fois les applications grand public et d’entreprise, Microsoft a introduit en septembre 2018 un endpoint commun de publication des métadonnées de clés
- Dans le cadre de cette unification, la documentation a été mise à jour afin de clarifier les exigences de validation du scope des clés selon les comptes grand public et d’entreprise
- Une API permettant de vérifier cryptographiquement les signatures était fournie, mais la bibliothèque n’a pas été mise à jour pour effectuer automatiquement la validation du scope (corrigé depuis)
- Le système de messagerie a été mis à jour en 2022 pour utiliser l’endpoint commun de métadonnées
- Les développeurs du système de messagerie ont supposé à tort que la bibliothèque effectuait une validation complète, et n’ont pas ajouté la validation de l’issuer/du scope nécessaire
- Résultat : le système de messagerie a accepté des requêtes d’email d’entreprise avec des jetons de sécurité signés par une clé grand public (corrigé depuis via une bibliothèque mise à jour)
Revue post-incident et mesures d’amélioration
- Identification et résolution de la condition de concurrence ayant permis qu’une clé de signature soit incluse dans un crash dump
- Renforcement de la prévention, de la détection et de la réponse en cas d’inclusion incorrecte de matériel de clé dans un crash dump
- Renforcement de l’analyse des identifiants afin de mieux détecter la présence de clés de signature dans l’environnement de débogage
- Déploiement d’une bibliothèque améliorée automatisant la validation du scope des clés dans la bibliothèque d’authentification, et clarification de la documentation associée
Mise à jour supplémentaire du 12 mars 2024
- L’hypothèse centrale reste qu’une erreur opérationnelle a permis à du matériel de clé de sortir de l’environnement de signature des jetons de sécurité et d’être accessible dans l’environnement de débogage via le compte compromis d’un ingénieur, sans changement concernant l’impact client, l’impact sur Microsoft ni l’activité de l’acteur
- Il avait été indiqué qu’un crash dump de 2021 pouvait être à l’origine de l’accès de l’acteur, mais aucun crash dump contenant le matériel de clé affecté n’a été retrouvé
- La condition de concurrence mentionnée n’affectait pas la présence ou non de la clé dans le crash dump, mais la possibilité pour ce crash dump d’être exporté hors de l’environnement de signature sécurisé
- L’affirmation selon laquelle l’export du crash dump était conforme aux procédures standard de débogage signifiait qu’il n’était pas interdit à l’époque ; les procédures standard actuelles de Microsoft interdisent désormais l’export de ce type de données hors de l’environnement de production
- L’enquête en cours a révélé des limites dans la technologie d’analyse des identifiants, qui seront corrigées au fur et à mesure de leur identification
1 commentaires
Commentaires Hacker News
Il semble manquer un maillon dans l’histoire : on peut facilement comprendre qu’un bug de concurrence ou de sécurité mémoire puisse faire atterrir par accident une clé privée dans des artefacts de débogage, mais l’attaquant devait aussi connaître l’existence du crash, la structure du dump de crash, et attendre à l’intérieur du réseau interne de Microsoft, non ?
La défense en partant du principe qu’il y aura compromission est une bonne stratégie de sécurité réseau, mais il ne faut pas simplement accepter comme hypothèse qu’il y a effectivement eu compromission.
Ce genre de données est souvent conservé de façon insuffisamment sécurisée au regard de sa valeur réelle. Pour avoir travaillé chez FAANG, j’ai vu que presque toutes les nouvelles recrues sans expérience dans la finance ou les environnements d’entreprise réglementés pensent qu’il est acceptable de joindre des données de crash à un bug tracker. Il faut donc changer les habitudes pour que les dumps de crash soient placés dans un coffre suffisamment facile à utiliser pour que les gens n’aient pas envie de le contourner.
Avec un compte d’ingénieur compromis, il faut supposer qu’il a au moins accès au bug tracker, et probablement qu’il peut aussi obtenir ou générer les symboles de débogage des binaires. Il ne reste plus qu’à attendre qu’un ingénieur téléverse par négligence un dump de crash en pièce jointe d’un bug, puis à le récupérer avant que quelqu’un ne s’en aperçoive et le supprime.
Par ailleurs, l’outil d’analyse des identifiants de Microsoft n’a pas trouvé la clé, et ce problème a été corrigé ; la clé semble donc avoir été sous une forme détectable par scan.
Dans l’ensemble, on dirait qu’un ingénieur a déplacé le dump contenant la clé vers son propre compte, l’a laissé là un certain temps, puis qu’un attaquant a compromis le compte, récupéré tous les fichiers utilisables, et est tombé sur le jackpot en scannant les clés avec de meilleurs outils que Microsoft.
Autrement dit, soit l’attaquant était déjà dans le réseau et a trouvé le dump par hasard lors d’un scan non détecté, soit il visait ce compte précis dès le départ.
Cela dit, du point de vue de l’attaquant, l’enchaînement des événements donne l’impression d’un coup de chance un peu trop parfait.
Il existe des cours d’ingénierie des systèmes qui expliquent comment de petits problèmes s’enchaînent dans un ordre précis jusqu’à provoquer une défaillance catastrophique. On peut dire que c’est ce qui s’est passé ici.
Il faut d’abord une condition de concurrence, puis que cette condition produise un résultat inattendu. Si le code a été testé et largement utilisé, il est possible que la probabilité en soit déjà inférieure à 10 %. Ensuite, un ingénieur doit justement décider qu’il a besoin de ce dump de crash, le logiciel de scan des identifiants doit ne pas détecter cet identifiant précis, un compte doit être compromis et donner accès au réseau, cet utilisateur doit avoir accès audit dump, puis le hacker doit le trouver et l’emporter.
Malgré tout, la clé était ancienne et ne devait permettre l’accès qu’à des comptes e-mail grand public, donc cela aurait dû être sûr ; mais il y avait aussi un bug qui acceptait les anciennes clés, et un autre qui ne rejetait pas cette clé de signature pour les jetons des comptes e-mail d’entreprise.
C’est une bonne leçon d’ingénierie des systèmes. Quels que soient les efforts, si suffisamment de petites choses s’accumulent, un gros incident finit par arriver ; il faut donc concevoir les systèmes de sorte que, même en cas d’explosion, le rayon d’impact reste limité.
Les analyses post-mortem présentent cela comme une accumulation aléatoire d’événements malchanceux. Comme si l’attaquant avait visé Microsoft par hasard, qu’il y avait eu par hasard une condition de concurrence, qu’un crash était survenu par hasard, et qu’il avait trouvé par hasard un dump de crash quelque part.
Mais il faut aussi envisager la possibilité que le bug initial de condition de concurrence ait été introduit intentionnellement. Le crash a pu être provoqué délibérément, l’attaquant a pu attendre qu’un dump apparaisse à un emplacement précis, et il a même pu y avoir un complice.
L’écosystème Microsoft ressemble à une voiture en Lego bricolée par les enfants du quartier avec des pièces que chacun a rapportées de chez lui.
Quand on parle de condition de concurrence, les gens disent « probabilité inférieure à 10 % », mais en réalité cela se produit peut-être à chaque gros crash ; c’est juste que les crashs ne sont pas fréquents.
Dieu seul sait pourquoi le masquage n’a pas été fait avant l’écriture sur disque.
Le fait que plus de la moitié du monde économique occidental dépende d’Outlook.com est très proche d’une situation gravement malsaine, mais les incitations financières actuelles ne vont pas dans le sens de la résilience ni du démantèlement d’entités hypercentralisées comme Outlook.com, donc ce genre d’événement continuera probablement de se produire.
Certains points ne sont pas clairement expliqués : si cela a été détecté le 11 juillet 2023 et que l’on soupçonne que l’incident s’est produit en avril 2021, cela signifie que l’attaquant disposait de ces identifiants depuis plus de deux ans, et qu’il a fallu deux mois entre la détection et la divulgation
Il manque aussi le nombre de jetons falsifiés et l’étendue des accès obtenus. En l’absence de divulgation, on est poussé à faire des hypothèses défavorables
Il n’y a pas non plus de calendrier entre la détection et l’application du correctif, seulement l’affirmation que « ce problème a été corrigé ». On ne peut qu’espérer qu’ils l’ont corrigé rapidement
Ils ont corrigé les 4 problèmes directs, mais il semble clairement y avoir un problème systémique, et on ne voit pas non plus ce qu’ils comptent faire à ce sujet
https://en.m.wikipedia.org/wiki/Adverse_inference
Une compromission de ce type exige une compréhension très profonde de l’infrastructure interne de Microsoft. Il est prudent de supposer qu’il s’agissait du travail organisé d’une équipe de hackers
Ce n’est pas quelque chose que l’on fait à bas coût, mais la récompense est énorme. L’hypercentralisation pousse les hackers à concentrer leurs efforts sur un petit nombre de cibles à très forte valeur, car le gain est colossal en cas de succès
Je suis presque certain qu’il existe déjà des équipes de hackers soutenues par des États qui étudient et analysent en profondeur l’infrastructure interne d’acteurs comme Google, Microsoft ou Amazon. Cette compromission montre à quel point ils la comprennent déjà bien
Je pense qu’il est temps de décentraliser à l’intérieur d’un périmètre de sécurité plus large
Si l’on enlève les formulations prudentes, quelqu’un a téléchargé un minidump depuis l’environnement de production vers un poste de développement, et celui-ci a probablement traîné quelque part dans le OneDrive interne de ce développeur jusqu’à ce que son compte soit compromis. Quelqu’un a récupéré le dump, trouvé la clé, et touché le jackpot
Dire que « quelques bugs obscurs ont été exploités de manière sophistiquée » semble un peu à côté de la plaque. Cela ressemble plutôt à une cascade d’erreurs où aucun des systèmes de sécurité n’a fait son travail
Je ne comprends pas pourquoi ils n’ont pas utilisé de HSM. Le but central de ce type de matériel n’est-il pas précisément d’empêcher l’exfiltration de matériel de clés ?
[1] https://www.futurex.com/download/excrypt-ssp-enterprise-v-2-...
Cela signifie que la clé n’était pas stockée dans un matériel irrécupérable, mais qu’elle était accessible par un simple processus serveur, du code compilé ordinaire exécuté dans un environnement hautement privilégié
Il n’est pas non plus indiqué que le système pouvant accéder à cette clé se trouvait dans un environnement séparé de l’environnement d’exploitation standard. On peut donc supposer que n’importe quelle machine de production pouvait accéder à la clé, et que toute personne ayant accès à cet environnement pouvait potentiellement exfiltrer le matériel de clé
En regardant la section de validation de https://learn.microsoft.com/en-us/azure/active-directory/dev..., sauf si j’ai manqué quelque chose, il semble toujours manquer l’importance de vérifier la date de l’émetteur ou son éventuelle révocation
Ce n’est pas non plus dans le pseudocode, ce qui laisse penser qu’il pourrait exister d’autres implémentations qui font confiance à n’importe quelle clé que Microsoft a un jour publiée. Hors exceptions comme l’effacement de cache, c’est bien ce que cela implique
Si même Microsoft n’arrive pas à utiliser correctement sa propre plateforme d’identité dans l’un de ses produits phares, Outlook, quelles chances les autres ont-ils ?
Ils se sont contentés de vérifier qu’elle avait été signée par l’AC de Microsoft. C’est un problème tellement évident qu’il est difficile d’imaginer qu’il ait pu passer une revue de code
L’une des raisons pour lesquelles ils se sont vraiment fait avoir semble être qu’ils n’avaient pas fait de rotation de la clé. On a l’impression qu’un laps de temps assez long s’est écoulé entre le moment où la clé a été déplacée vers un endroit où elle n’aurait pas dû se trouver et le moment où elle a effectivement été volée
Si la clé avait été remplacée régulièrement, il aurait été impossible de falsifier des jetons avec celle-ci
Je ressens la même chose à chaque fois que ce genre d’article paraît : le fait de confier à des entreprises privées la réponse à une attaque de niveau étatique, simplement parce que l’attaque est numérique et non physique, me paraît vraiment étrange.
Si un avion de chasse chinois abattait un avion FedEx au-dessus du Pacifique, ce serait considéré comme une attaque contre la souveraineté américaine et le gouvernement réagirait de façon appropriée. Personne ne s’attendrait non plus à ce que FedEx possède sa propre escadrille de chasse pour protéger ses avions cargo. Personne ne dirait non plus : « c’est la faute de FedEx, ils n’avaient qu’à assurer correctement leur défense antiaérienne ».
Mais dès qu’on entre dans le domaine numérique, on semble accepter que Microsoft doive se défendre seule contre la Chine et la Russie.
Les gouvernements arrêtent assez régulièrement des agents étrangers, mais ces arrestations ne débouchent pas sur une guerre totale.
Deuxièmement, les États-Unis font eux aussi ce genre de choses en permanence, y compris à des pays alliés, ce qui rend difficile de justifier des mesures plus fortes.
L’ampleur et le volume des cyberattaques sont très importants, mais je comprends que les États-Unis mènent eux aussi beaucoup d’attaques extérieures d’une ampleur comparable.