Une faille critique d'Azure Entra ID met en évidence les problèmes d'IAM de Microsoft. Bien que la vulnérabilité du cloud ait été corrigée avant sa divulgation, le chercheur qui l'a découverte affirme qu'elle aurait pu conduire à des attaques catastrophiques, ce qui a alarmé certains membres de la communauté de la sécurité.Microsoft Entra ID (anciennement Microsoft Azure Active Directory ou Azure AD) est une solution de gestion des identités et des accès (IAM) basée sur le cloud. Il s'agit d'un service de gestion des répertoires et des identités qui fonctionne dans le cloud et offre des services d'authentification et d'autorisation à divers services Microsoft, tels que Microsoft 365, Dynamics 365, Microsoft Azure et des services tiers.
Entra ID propose différentes méthodes d'authentification, notamment l'authentification par mot de passe, l'authentification multifactorielle, l'authentification par carte à puce et l'authentification par certificat. Il comprend également plusieurs fonctionnalités de sécurité, telles que des politiques d'accès conditionnel, l'authentification basée sur les risques et la protection de l'identité.
En 2024, Microsoft a été au cœur d'une polémique concernant la perte de plus de deux semaines de journaux de sécurité pour certains de ses produits cloud. Cet incident, qui s'est produit entre le 2 et le 19 septembre 2024, a été attribué à un bogue dans l'un des agents de surveillance internes de l'entreprise. Ce problème a empêché l'envoi des données de journal vers la plateforme de journalisation interne de Microsoft, laissant les défenseurs des réseaux sans données cruciales pour détecter d'éventuelles intrusions.
Récemment, une vulnérabilité critique de l'authentification Microsoft aurait pu permettre à un acteur malveillant de compromettre pratiquement tous les locataires Entra ID dans le monde. La vulnérabilité d'élévation de privilèges (EoP), référencée sous le numéro CVE-2025-55241, a été corrigée au cours de l'été et divulguée au début du mois, mais rien n'indique que cette faille, qui avait initialement reçu une note CVSS de 9,0 avant d'être reclassée à 10,0, ait été exploitée dans la nature. Cela dit, selon le chercheur qui a découvert la faille, cette vulnérabilité aurait pu être utilisée pour mener des attaques dévastatrices et met en évidence un manque de sécurité autour des composants clés de la pile d'authentification d'Azure.
Selon Dirk-jan Mollema, chercheur en sécurité et fondateur du cabinet de conseil néerlandais Outsider Security, la vulnérabilité provient d'une défaillance d'authentification dans l'API Azure AD Graph. Ce service, dont la suppression est prévue cette année, est une API REST qui permet aux utilisateurs d'accéder aux ressources cloud Azure, notamment Entra ID (anciennement Azure Active Directory ou Azure AD).
Selon Mollema, cette défaillance d'authentification permet à des utilisateurs non autorisés de tirer parti d'un autre problème de sécurité qu'il a découvert, appelé « Actor tokens ». Ces jetons non documentés, conçus pour les communications de service à service en arrière-plan, ne sont pas soumis à des politiques de contrôle d'accès et, surtout, peuvent être utilisés pour élever des privilèges.
Mollema a découvert que la vulnérabilité d'authentification dans l'API Azure AD Graph pouvait créer des jetons d'usurpation d'identité et les utiliser pour un accès inter-locataires. « Concrètement, cela signifie qu'avec un jeton que j'ai demandé dans mon locataire de laboratoire, je pouvais m'authentifier en tant que n'importe quel utilisateur, y compris les administrateurs globaux, dans n'importe quel autre locataire ».
Mollema a découvert cette faille en juillet alors qu'il préparait sa présentation pour les conférences Black Hat USA 2025 et DEF CON 33 à Las Vegas, intitulée « Advanced Active Directory to Entra ID Lateral Movement Techniques » (Techniques avancées de déplacement latéral d'Active Directory vers Entra ID). La présentation détaillait en partie comment les acteurs malveillants peuvent abuser des jetons Actor non signés, qui sont générés par ce qu'il considère comme un service hérité appelé « Access Control Service » (service de contrôle d'accès).
Les jetons d'authentification non signés sont particulièrement dangereux en soi, mais Mollema a constaté que le jeton Actor présentait un risque encore plus grand car il « manque de presque tous les contrôles de sécurité que l'on pourrait souhaiter ». Par exemple, ils ne peuvent pas être révoqués pendant leur durée de vie de 24 heures, ils contournent les politiques d'accès conditionnel et leur visibilité est extrêmement limitée.
« La demande de jetons Actor ne génère pas de journaux », a écrit Mollema. « Même si c'était le cas, ils seraient générés dans mon locataire plutôt que dans celui de la victime, ce qui signifie qu'il n'y a aucune trace de l'existence de ces jetons. » Lorsqu'il a testé les jetons Actor, il a modifié certains de leurs champs pour voir s'ils fonctionnaient toujours. Dans un test, il a changé l'ID du locataire du jeton pour quelque chose de complètement différent : un locataire de son compte de test.
Lorsqu'il a essayé d'accéder au nouveau locataire via Azure AD Graph, Mollema a reçu un message d'erreur indiquant que le jeton Actor était valide, mais que l'identité de l'utilisateur était introuvable dans le locataire. Il a alors trouvé un netID (c'est-à-dire un identifiant utilisateur pour Azure AD Graph) pour le nouveau locataire et découvert que son accès était autorisé. « J'ai testé cela sur quelques autres locataires test auxquels j'avais accès, pour m'assurer que je n'étais pas fou, mais je pouvais effectivement accéder aux données d'autres locataires, à condition de connaître leur identifiant de locataire (qui est une information publique) et l'identifiant réseau d'un utilisateur de ce locataire », a-t-il écrit.
Bien que les identifiants réseau ne soient pas publics, Mollema a découvert que les identifiants utilisateur sont générés de manière incrémentielle et sont donc vulnérables aux attaques par force brute. De plus, Mollema a découvert qu'en modifiant les jetons Actor et en devinant l'identifiant netID d'un administrateur global, il pouvait obtenir un accès illimité à ce locataire, sans laisser aucune trace dans les journaux. « Sans l'absence totale de mesures de sécurité dans ces jetons, je ne pense pas qu'un impact aussi important avec une télémétrie aussi limitée aurait été possible », a-t-il écrit.
Mollema explique que, bien que l'API Azure AD Graph soit prévue pour être retirée cette année, de nombreuses applications Microsoft l'utilisent encore. « Je ne pense pas que le plan de retrait ait eu un impact sur la vulnérabilité, mais une API en voie de disparition n'est pas susceptible de bénéficier d'une attention particulière de la part des ingénieurs pour « moderniser » le code et/ou l'authentification », dit-il.
Si l'échec de l'authentification avec Azure AD Graph permet l'accès inter-locataires, Mollema estime que le problème le plus important concerne les jetons Actor, qui, selon lui, n'auraient jamais dû exister. Il existe un flux de jetons OAuth conçu pour empêcher ce type de scénarios d'usurpation d'identité, mais il n'a pas été suivi, explique-t-il. « Dans ce flux, le fournisseur d'identité émet un jeton signé, qui ne peut donc pas être modifié. Cela signifie également que des journaux sont générés lorsque ces jetons sont émis, ce qui nous permet d'avoir au moins un certain niveau d'audit », explique Mollema. « À mon avis, ce sont là des propriétés importantes qui devraient être mises en place dans un protocole d'usurpation d'identité. »
Les recherches de Mollema ont, à juste titre, alarmé de nombreux membres de la communauté de la sécurité de l'information. Dans un message publié sur la plateforme de...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.