- L’incident Storm-0558 était connu comme une compromission d’Exchange Online et d’Outlook.com, mais des analyses indiquent que la clé de signature MSA compromise pouvait aussi être exploitée pour falsifier des jetons OpenID v2.0 d’applications Azure AD
- Le périmètre potentiellement touché s’étend aux applications Microsoft utilisant l’authentification par compte Microsoft personnel, aux applications clientes avec « Login with Microsoft » et même à certaines applications multitenant sous conditions
- La clé publique concernée figurait dans la liste des clés OpenID de Microsoft au moins depuis 2016, a été remplacée entre le 27 juin et le 5 juillet 2023, et correspond à l’acquired signing key et au thumbprint publiés par Microsoft
- Microsoft a révoqué la clé, ce qui bloque la création de nouveaux faux jetons, mais les applications qui continuent de faire confiance à des sessions créées avant la révocation ou à un ancien cache de clés publiques doivent être vérifiées séparément
- Les faux jetons pouvant être créés hors ligne, aucune trace d’émission n’apparaît dans le portail Azure et, sans jeton brut ni journaux
kid, il est très difficile de confirmer une compromission
Une portée qui dépasse Exchange Online
- Microsoft et la CISA ont révélé un incident de sécurité ayant affecté plusieurs clients d’Exchange Online et d’Outlook.com
- Selon Microsoft, Storm-0558, désigné comme un acteur lié à la Chine, a obtenu une clé MSA privée et a falsifié des jetons d’accès pour Outlook Web Access et Outlook.com
- L’acteur de la menace aurait aussi exploité deux problèmes de sécurité présents dans le processus de validation des jetons de Microsoft
- D’après l’analyse de Wiz Research, la clé compromise ne se limitait pas à Outlook.com et Exchange Online, et pouvait aussi servir à falsifier des jetons d’accès pour plusieurs applications Azure Active Directory
- applications prenant en charge l’authentification par compte personnel
- applications gérées par Microsoft comme SharePoint, Teams et OneDrive
- applications clientes prenant en charge « Login with Microsoft »
- applications multitenant dans certaines conditions
Comment la clé compromise a été identifiée
- Le 11 juillet 2023, Microsoft a indiqué qu’un acteur malveillant avait obtenu la MSA consumer signing key et pouvait falsifier des jetons d’accès pour des comptes Exchange Online et Outlook.com
- Wiz a étudié la documentation officielle de Microsoft sur la validation des jetons OpenID afin d’identifier les clés capables de signer des jetons OpenID pour des comptes Microsoft et des applications Azure Active Directory
- À l’époque, les applications Azure v2.0 pour comptes personnels dépendaient de 8 clés publiques, tandis que les applications Azure multitenant v2.0 avec comptes Microsoft activés dépendaient de 7 clés publiques
- D’après l’Internet Archive Wayback Machine, l’une des clés publiques présente dans la liste au moins depuis 2016 a été remplacée entre le 27 juin et le 5 juillet 2023
- Ce calendrier correspond au moment du remplacement de la clé obtenue mentionné par Microsoft dans son billet de blog
- Le certificat de l’ancienne clé publique a été émis le 5 avril 2016 et a expiré le 4 avril 2021
- Son thumbprint correspond à la valeur publiée par Microsoft dans son dernier billet comme « Thumbprint of acquired signing key »
- D’après l’analyse, la clé obtenue par Storm-0558 était une clé privée du tenant MSA de Microsoft, mais pouvait aussi signer des jetons OpenID v2.0 pour plusieurs applications Azure Active Directory
Pourquoi la compromission d’une clé de signature OpenID est dangereuse
- La plateforme Azure identity publie différentes listes de clés publiques de confiance selon le type d’application, et s’en sert pour vérifier l’intégrité des jetons émis par Azure Active Directory
- Les applications AAD valident la signature d’un jeton à l’aide de la bonne liste de clés publiques avant de décider si ce jeton est digne de confiance
- Si une clé présente dans cette liste est compromise, les applications qui valident avec cette liste peuvent, dans certaines conditions, accepter des faux jetons d’accès comme valides
- Selon ce que Wiz déduit du billet de Microsoft, Storm-0558 semble avoir eu accès à l’une des nombreuses clés utilisées pour signer et valider les jetons d’accès AAD
- La clé compromise était reconnue pour signer des jetons d’accès OpenID v2.0 destinés à des applications AAD pour comptes personnels et mixed audience, c’est-à-dire multitenant ou ciblant les comptes personnels
- En conséquence, Storm-0558 pouvait en théorie falsifier des jetons permettant de s’authentifier comme n’importe quel utilisateur dans les applications affectées faisant confiance aux certificats Microsoft OpenID v2.0 mixed audience et comptes personnels
- Les clés de signature d’un identity provider peuvent être considérées comme des secrets encore plus puissants que des clés TLS
- Même si une clé TLS fuit, l’attaquant doit encore usurper le serveur concerné pour élargir l’impact
- Une clé d’identity provider peut servir à falsifier des jetons donnant en une seule étape accès à des boîtes mail, services de fichiers ou comptes cloud
- Le même risque s’applique non seulement à Microsoft, mais aussi à la fuite de clés de signature chez de grands identity providers comme Google, Facebook ou Okta
Types d’applications affectés
- Les systèmes touchés se limitent aux applications Azure Active Directory utilisant OpenID v2.0 de Microsoft
- Les applications v1.0 ne sont pas affectées, car elles n’utilisent pas la clé compromise pour valider les jetons
-
Applications prenant uniquement en charge les comptes Microsoft personnels
- Les applications Azure Active Directory utilisant le protocole Microsoft v2.0 et prenant en charge « Personal Microsoft accounts only » sont affectées
- Cela inclut des applications gérées par Microsoft comme Outlook, SharePoint, OneDrive et Teams, ainsi que des applications clientes prenant en charge l’authentification par compte Microsoft
-
Applications prenant en charge à la fois le multitenant et les comptes Microsoft personnels
- Les applications Azure Active Directory prenant en charge une « mixed audience » et utilisant le protocole Microsoft v2.0 sont également affectées
- L’acteur de la menace pouvait falsifier des jetons d’accès valides pour usurper des utilisateurs connectés avec un compte Microsoft personnel
- Microsoft a introduit une extension du protocole OpenID afin de limiter la capacité d’une clé MSA à usurper des comptes d’organisation
- Les développeurs doivent vérifier le claim issuer en le comparant au champ issuer de la liste de clés publiques OpenID
- Cette validation vise à empêcher qu’une clé MSA signe des jetons d’accès avec un issuer autre que le tenant MSA
- Cette extension est spécifique à Microsoft, et sa mise en œuvre relève de la responsabilité du propriétaire de l’application
- Wiz estime que de nombreuses applications pourraient ne pas avoir cette procédure de validation, ce qui laisserait subsister une possibilité d’usurpation de comptes d’organisation
- Selon le billet de Microsoft, OWA est aussi affecté par un problème similaire
- Microsoft a ajouté cette vérification le 12 juillet dans le SDK Azure officiel
-
Applications ne prenant en charge que le multitenant
- Une application multitenant est affectée si elle a été configurée pour dépendre du point de terminaison de clés v2.0 common au lieu de « Organizations »
- Une telle configuration doit être considérée comme incorrecte
- La documentation officielle de Microsoft ne précise pas clairement quand utiliser le point de terminaison « common », de sorte que certaines applications multitenant peuvent aussi être concernées
-
Applications single-tenant
- Les applications single-tenant qui ne prennent en charge que « Accounts in this organizational directory only » ne sont pas affectées
Conditions nécessaires à la falsification de jetons
- Lors de la validation d’un jeton OpenID, les développeurs doivent vérifier que le jeton a été signé par une clé privée autorisée pour le périmètre visé et que le champ
audcorrespond au périmètre de l’application cible - Les applications récupèrent les certificats autorisés pour la validation de signature via un point de terminaison de métadonnées appelé
jwks_uri - L’acteur de la menace peut créer un jeton JWT, y renseigner des données comme l’adresse e-mail de la victime, puis le signer avec la clé compromise enregistrée sur le point de terminaison de certificats publics Azure Active Directory afin de produire un faux jeton d’accès valide
- À titre d’exemple, le
kidde la clé compromise mentionné est1LTMzakihiRla_8z2BEJVXeWMqo - Selon les directives de Microsoft, pour qu’un jeton soit valide, le claim
issdoit correspondre à l’issuer du tenant MSA indiqué par le point de terminaisonjwks_uri, et le claimtiddoit également être l’ID du tenant MSA9188040d-6c67-4c5b-b112-36a304b66dad - Dans les applications AAD mixed audience, tant qu’il s’agit d’usurper un compte personnel, un jeton signé par le tenant MSA pour un compte Azure AD peut être considéré comme valide
- Les détails de validation des ID Token sont disponibles dans les directives officielles de Microsoft
Risques persistants après la révocation de la clé
- Microsoft ayant révoqué la clé compromise, les applications Azure Active Directory n’acceptent plus comme valides les jetons falsifiés avec cette clé
- Même les jetons configurés avec une longue durée de validité sont rejetés par les applications
- En revanche, si des sessions avaient déjà été créées dans des applications clientes avant la révocation de la clé, l’acteur de la menace a pu établir une persistance en exploitant les permissions de l’application
- émission de clés d’accès propres à l’application
- mise en place de backdoors spécifiques à l’application
- cas où Storm-0558, avant l’action de Microsoft, a falsifié un jeton d’accès pour OWA afin d’obtenir un jeton Exchange Online valide
- Les applications qui conservent une copie des clés publiques AAD antérieure à la révocation du certificat par Microsoft peuvent aussi être à risque
- Si elles utilisent un magasin local de certificats ou des clés en cache et continuent de faire confiance à la clé compromise, elles restent vulnérables à la falsification de jetons
- Microsoft recommande d’actualiser les magasins locaux et les caches de certificats au moins une fois par jour
Ce que les utilisateurs Azure doivent vérifier
- Pour déterminer si la clé compromise a été utilisée dans votre environnement, il faut identifier les applications potentiellement affectées, rechercher des traces d’utilisation de faux jetons et utiliser les Indicators of Compromise publiés par Microsoft afin de vérifier l’activité des IP associées
- Si des applications mettent en cache les certificats publics OpenID de Microsoft, il faut rafraîchir ce cache
- Microsoft a intégré dans le SDK Azure officiel une validation supplémentaire destinée à empêcher l’authentification de comptes d’organisation avec une clé MSA, et les utilisateurs de ce package doivent passer à la dernière version
Pourquoi la détection est difficile
- L’acteur de la menace pouvant falsifier des jetons d’accès hors ligne, aucune trace d’émission de jeton n’apparaît dans le portail Azure
- Pour vérifier l’usage de la clé, les clients cloud doivent examiner les journaux propres à chaque application AAD potentiellement affectée
- Selon Wiz, les applications concernées sont celles qui utilisaient les points de terminaison suivants pour valider des jetons d’accès Microsoft v2.0
- Les applications AAD potentiellement affectées peuvent être identifiées avec l’Azure CLI en recherchant celles dont
signinaudiencevautAzureADMultipleOrgs,AzureADandPersonalMicrosoftAccountouPersonalMicrosoftAccount - Les applications AAD redirigées vers Azure WebApps peuvent également être trouvées via une requête CLI distincte
- En décodant les jetons d’accès utilisés par l’application et en vérifiant si le champ
kidde l’en-tête JOSE contient la chaîne1LTMzakihiRla_8z2BEJVXeWMqo, il est possible d’identifier les jetons signés avec la clé compromise - Selon Microsoft, la clé compromise était inactive, donc tout jeton d’accès signé avec cette clé doit être considéré comme suspect
- Il n’existe pas de pratique normalisée en matière de journalisation applicative
- Beaucoup de propriétaires d’applications ne disposent ni des jetons d’accès bruts ni de journaux détaillés contenant la clé de signature
- Cela peut rendre l’identification des événements et l’enquête extrêmement difficiles
- Dans les applications AAD multitenant qui ne prennent pas en charge les comptes Microsoft personnels, les claims
issettidpeuvent permettre de détecter un faux jeton- Toute tentative de connexion avec un jeton d’accès signé par l’ID de tenant MSA
9188040d-6c67-4c5b-b112-36a304b66dadpeut indiquer l’utilisation de la clé compromise
- Toute tentative de connexion avec un jeton d’accès signé par l’ID de tenant MSA
- Si les HTTP Logs sont activés sur une WebApp, il est possible via Log Analytics de vérifier si des adresses IP associées à l’acteur de la menace, mentionnées dans le billet de Microsoft, ont accédé à l’application
Questions ouvertes et conclusion pratique
- L’impact global est bien plus important que ce qui avait été initialement indiqué, et pourrait avoir des effets de long terme sur la confiance dans le cloud, en particulier dans l’identity layer, composant fondamental du cloud
- Les applications potentiellement vulnérables se comptaient par millions, incluant à la fois des applications Microsoft et des applications clientes, et beaucoup ne disposent pas de journaux suffisants pour déterminer si elles ont été compromises
- Les propriétaires d’applications doivent en priorité mettre à jour l’Azure SDK vers la dernière version et vérifier que le cache de leur application a bien été actualisé
- Les applications dont le cache n’a pas été mis à jour peuvent rester vulnérables à un acteur de la menace utilisant la clé compromise
- L’enquête est toujours en cours, et les informations publiques ne permettent pas encore de répondre clairement à la manière dont la clé a été obtenue, au moment exact de la compromission, ni à l’éventuelle compromission d’autres clés
1 commentaires
Avis sur Hacker News
Les clés de signature des fournisseurs d’identité sont sans doute parmi les secrets les plus puissants aujourd’hui. Par exemple, elles sont bien plus critiques que les clés TLS
À bien des égards, elles sont du même ordre que les clés d’une autorité de certification (CA), et les organisations qui utilisent les services Microsoft et Azure devraient évaluer l’impact potentiel
On dirait que les gens ont oublié le vieux dicton : « ne mettez pas tous vos œufs dans le même panier »
Je me demande pourquoi l’architecture fait que des dizaines, des centaines, voire peut-être des milliers de serveurs partagent un petit nombre de clés
Où sont les clés racine basées sur HSM, les clés intermédiaires par datacenter, les clés de signature éphémères par serveur, les listes de révocation de certificats ?
Je me demande s’il est même possible de protéger correctement les bearer tokens contre ce type d’attaque, ou s’il faut revenir à un modèle où l’on présente un nonce au service d’origine pour récupérer la charge utile de manière sûre
En gros, certaines fonctionnalités ne deviennent utilisables que si l’on rassemble les œufs au même endroit
J’ai préparé le pop-corn pour le jour où tout s’écroulera, et une chose est sûre : l’entreprise ne s’en imputera pas la faute
Est-ce que ça veut simplement dire utiliser un autre fournisseur qui, lui, n’aurait pas perdu ses clés ?
On dirait qu’il ne reste plus, de fait, qu’environ quatre géants de la tech
La conclusion a été que « la clé MSA compromise aurait pu permettre à l’attaquant de forger des jetons d’accès pour plusieurs types d’applications Azure Active Directory »
Cela inclut SharePoint, Teams, OneDrive, les applications clientes prenant en charge « Se connecter avec Microsoft », ainsi que toutes les applications prenant en charge l’authentification des comptes personnels, comme les applications multitenant sous certaines conditions
J’espère que le récent renommage d’Azure AD en Entra ID par Microsoft n’est qu’une coïncidence : https://devblogs.microsoft.com/identity/aad-rebrand/
Quand je pense à un produit de sécurité, je n’ai pas envie de penser à un fournisseur qui “fait entrer” les gens au lieu de tenir les acteurs malveillants dehors. entra vient de entrar, c’est-à-dire entrer/rentrer /s
En espagnol, c’est même l’impératif, ce qui donne l’impression d’ordonner à quelqu’un : « entre ! »
« Le certificat de la clé publique existante a été émis le 5 avril 2016 et a expiré le 4 avril 2021, et son empreinte correspondait à celle de la clé que Microsoft a présentée dans son dernier billet de blog comme l’“empreinte de la clé de signature acquise” »
Si je lis bien, cela signifie que la clé était expirée mais continuait à être utilisée ?
Je me demande si quelqu’un sait laquelle Microsoft utilisait, quel qu’ait été l’usage de ces clés
L’une est la méthode de vérification TLS : lorsqu’on vérifie une chaîne de certificats où Cn est signé par Cn-1, puis ainsi de suite jusqu’à C0, cela fonctionne à peu près ainsi
1 time_check = now()
2 for cert in Cn to C0
3 if time_check < cert.valid_from || time_check > cert.valid_to
4 return EXPIRED
5 return NOT_EXPIRED
On vérifie la date d’expiration de chaque certificat par rapport à l’heure actuelle
L’autre est la méthode utilisée pour la signature de code, à peu près comme ceci
1 time_check = now()
2 for cert in Cn to C0
3 if time_check < cert.valid_from || time_check > cert.valid_to
4 return EXPIRED
5 time_check = cert.issue_time
6 return NOT_EXPIRED
Cn est vérifié par rapport à l’heure actuelle, et les autres par rapport au moment où ils ont signé le certificat immédiatement en dessous
Je comprends pourquoi la signature de code fonctionne ainsi. C’est essentiellement une notarisation numérique : un document déjà notarié ne doit pas cesser de l’être simplement parce que, plus tard, le notaire perd sa qualité et que sa licence expire
Et quand ils ont dit qu’« en raison d’un problème de validation, cette clé a pu être approuvée pour la signature de jetons Azure AD », il aurait fallu dire qu’« en raison de plusieurs problèmes de validation, cette clé a pu être approuvée pour la signature de jetons Azure AD »
Et quand ils ont dit que « les acteurs connaissaient bien l’environnement ciblé, les politiques de journalisation, les exigences d’authentification, ainsi que les politiques et procédures », ils auraient plutôt dû dire ceci
« Les acteurs visaient peut-être un coup audacieux de type hit-and-run et n’ont peut-être pas accordé une seconde d’attention à des détails comme les politiques. Ou bien les acteurs étaient inexpérimentés, au point de ne pas savoir que le Département d’État américain nous payait beaucoup plus cher pour le privilège de journaliser en détail les événements d’accès aux boîtes aux lettres. Boeing avait en quelque sorte donné un indice avec le MCAS. De plus, les acteurs semblent avoir négligé le fait que Chrome 92 a été mis à jour pour la dernière fois en 2021 et constituait un assez mauvais choix de user-agent pour attaquer des systèmes TIC de ministères américains censés utiliser des navigateurs à jour. Ils semblent aussi avoir très peu compris la manière dont les boîtes aux lettres du Département d’État américain sont accédées, et avoir fait de mauvaises suppositions en utilisant des datacenters publics aléatoires à travers l’Europe. »
[1] https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
[2] https://www.cisa.gov/news-events/cybersecurity-advisories/aa...
[3] https://www.theguardian.com/us-news/2023/jul/20/ambassador-t...
Il semble très peu probable que cette clé ait été dans un HSM
Je suis toujours surpris chaque fois que je vois une nouvelle indiquant qu’une clé qui aurait dû se trouver dans un HSM a été volée
J’ai récemment pu créer l’outil idéal pour combler le fossé entre les chaînes d’outils modernes et les enclaves de sécurité matérielles : https://keymux.com
Même compte tenu de l’échelle d’Azure AD, Microsoft n’aurait peut-être pas besoin de beaucoup de HSM pour la signature
Cela dit, les HSM ne sont pas particulièrement faciles à administrer, ce qui peut être l’une des raisons pour lesquelles ils ne sont pas utilisés aussi largement qu’ils devraient l’être
[1] https://cpl.thalesgroup.com/encryption/hardware-security-mod...
Premièrement, Microsoft a peut-être utilisé la clé de signature JWT en mémoire, et l’attaquant a pu l’obtenir par injection de code ou en accédant à l’image mémoire du processus concerné
Deuxièmement, Microsoft utilisait peut-être réellement un HSM, mais devait distribuer géographiquement la clé, et l’attaquant a pu y accéder au cours de ce processus
Le premier est plus probable, mais le second ne peut pas être exclu
Ne devrait-on pas légaliser le fait que les FAANG mènent des opérations de cyberguerre/espionnage les unes contre les autres ?
Ainsi, au lieu de compter sur l’ambiguïté, elles devraient au moins atteindre un niveau minimal de bonnes pratiques de sécurité
Tant que l’on ne cause pas de dommages réels ni ne télécharge de vraies données clients, et que l’on divulgue ce que l’on a trouvé, c’est déjà légal
Satya va devoir dire IA beaucoup plus souvent lors de la prochaine présentation des résultats s’il veut couvrir ce bazar
Il est difficile d’imaginer une compromission pire qu’une puissance étrangère accédant aux comptes e-mail de nos représentants chargés de traiter avec cette même puissance
J’espère que le gouvernement américain réexaminera sérieusement ses politiques consistant à déplacer l’informatique vers les grands fournisseurs de cloud
« Enfin, nous remercions l’équipe Microsoft qui a travaillé en étroite collaboration avec nous sur cet article et nous a aidés à en vérifier l’exactitude technique »
Comment la décision de publier cette information un vendredi a-t-elle été prise ?
J’ai cherché « microsoft » dans Google Actualités et abandonné après les 5 premières pages : il n’y avait que 2 mentions pertinentes au total
Le reste, c’était surtout des « news » du genre articles promotionnels, mise en avant de produits, bruit autour du cours de l’action
« L’impact global de cet incident est bien plus important que ce que nous avions compris au départ. Il aura des conséquences durables sur la confiance dans le cloud et dans les composants essentiels qui le soutiennent, surtout la couche d’identité, qui est la trame fondamentale de tout ce que nous faisons dans le cloud. Nous devons en tirer des enseignements et nous améliorer »
On pourrait peut-être commencer par ne pas tout mettre dans le cloud
Le problème n’est pas tant le cloud lui-même que, au bout du compte, une économie capitaliste dysfonctionnelle qui engendre des monopoles, ou des cartels de quelques grandes entreprises
Même quand, pour la longue traîne des petites entreprises, il n’est pas rationnel d’utiliser les produits et services des grands groupes, donner plus de pouvoir aux gagnants du marché finit par créer des entreprises too big to fail
Pour ces grands groupes, une seule erreur, un seul faux pas suffit à créer une surface d’attaque immense. Ce genre d’accident n’est pas une question de savoir s’il arrivera, mais quand
À long terme, si la société veut survivre, la réponse passe par des services fédérés, quitte à sacrifier une partie du confort
Les dirigeants d’entreprise ne sont pas des geeks rêvant de services fédérés plus grands et meilleurs
L’IT représente souvent un coût important, à la fois dans le compte de résultat et dans le temps et la douleur consacrés à apprendre, décider et se battre avec les problèmes informatiques
Pour prendre une analogie, si la météo est incertaine mais que vous choisissez Microsoft Airlines, même si le vol est annulé et que vous êtes en retard, vous aurez beaucoup de compagnie et de compassion
À l’inverse, si vous choisissez votre propre voie en prenant le train, toute la charge de comprendre les horaires, les gares, etc., vous retombe dessus. Parce que « l’avion, tout le monde connaît »
Et si Microsoft Air arrive sans encombre alors que votre train a un problème, vous vous retrouvez seul à attirer l’attention comme un tas fumant sur le carrelage de la cuisine
Excellente synthèse, et effrayante
Le sujet est complexe, mais c’était expliqué de façon facile à digérer