UnOAuthorized : Élévation des privilèges via les applications Microsoft

Cet article détaille une série de découvertes de l'équipe de recherche en sécurité de Semperis qui ont permis d'effectuer des actions dans Entra ID au-delà des contrôles d'autorisation prévus, sur la base de l'analyse de la portée OAuth 2.0 (permissions). Notre découverte la plus préoccupante concernait la capacité d'ajouter et de supprimer des utilisateurs de rôles privilégiés, y compris le rôle le plus puissant dans Entra ID : Administrateur global. Nous avons signalé nos découvertes au Microsoft Security Response Center (MSRC), et nous avons travaillé avec Microsoft pour nous assurer que ces découvertes ont été résolues.

Bien que l'on ne sache pas si des organisations ont été compromises précédemment par cette découverte dans la nature, un acteur de la menace aurait pu utiliser cet accès pour effectuer une élévation de privilèges à l'administrateur global et installer d'autres moyens de persistance dans un locataire. Un attaquant pourrait également utiliser cet accès pour effectuer un mouvement latéral dans n'importe quel système de Microsoft 365 ou Azure, ainsi que dans n'importe quelle application SaaS connectée à Entra ID.

La découverte exige que l'initiateur détienne le rôle d'administrateur d'application ou d'administrateur d'application en nuage dans Entra ID, qui est considéré comme privilégié. Dans de nombreuses entreprises, la triste réalité est que les utilisateurs qui se voient attribuer ces rôles ne sont pas traités comme des privilégiés, ce qui en fait des cibles de choix pour un attaquant.

Les organisations concernées doivent savoir comment détecter si leurs applications Microsoft ont pu être ciblées, comme indiqué plus loin dans cet article.

Introduction à l'intégration des applications

Pour comprendre ce vecteur d'attaque, il faut comprendre les éléments fondamentaux impliqués.

Les clients de Microsoft 365 et Azure connaissent peut-être les systèmes et services avec lesquels ils interagissent, notamment Microsoft Teams, SharePoint Online, Exchange Online, Azure Key Vault et les portails d'administration tels que le portail Azure et Microsoft 365 Admin Center, ainsi que la suite d'autres services Microsoft. Ce que vous ignorez peut-être, ce sont les centaines d'applications Microsoft qui assurent le fonctionnement de votre environnement Microsoft. En dehors de Microsoft, ces applications peuvent être qualifiées d'applications de première partie, car elles ne sont pas fournies par un éditeur de logiciels tiers.

Entra ID est la plateforme d'identité et le moteur d'autorisation de chaque environnement Microsoft 365 et Azure. Les clients qui fédèrent l'authentification à Okta, Ping Identity ou d'autres fournisseurs d'identité avec les services Microsoft doivent toujours gérer le modèle d'autorisation qui existe dans leur domaine Microsoft. Entra ID est le mécanisme d'autorisation sous-jacent qui permet à ces applications Microsoft d'interagir et de fonctionner les unes avec les autres, en utilisant les normes de l'industrie pour l'authentification et l'autorisation modernes : OpenID Connect et OAuth 2.0.

Chaque client Microsoft possède son propre locataire Entra (anciennement connu sous le nom d'Azure AD). Dans chaque locataire, chaque application Microsoft est représentée par un objet principal de sécurité connu sous le nom de principal de service. Les utilisateurs et les groupes sont les principaux de sécurité que nous connaissons tous le mieux ; vous pouvez attribuer des rôles et des autorisations à ces principaux. Tout comme les utilisateurs et les groupes, les rôles et les autorisations peuvent être attribués aux applications par le biais de leurs principaux de service. Ces rôles et permissions sont évalués lors de l'interaction avec Entra ID ou d'autres services Microsoft 365.

Applications multi-locataires dans Entra ID

Entra ID considère généralement toutes les applications Microsoft, même celles qui ont des propriétés uniques, comme des applications multitenant.

Avec les applications multitenant, le développeur définit le mode de fonctionnement de l'application dans l'enregistrement de l'application. Cela inclut des actions telles que la définition des autorisations API Microsoft Graph dont l'application a besoin, ainsi que l'identifiant utilisé par l'application pour accéder à Microsoft Graph. Microsoft Graph est le point de terminaison API unifié pour plusieurs services Microsoft, y compris Entra ID.

Lorsqu'une organisation consomme une application multilocataire, l'application est représentée dans le locataire consommateur par un principal de service(figure 1).

Le cas des références multiples

Entra ID permet l'attribution et l'utilisation de deux types d'identifiants pour l'authentification : les secrets (mots de passe) et les clés (certificats). L'un ou l'autre de ces types de justificatifs a fonctionné dans le contexte de notre découverte. À l'avenir, je désignerai collectivement les secrets et les clés par le simple terme d'informations d'identification.

Là où les choses deviennent intéressantes, c'est qu'Entra ID permet de stocker les informations d'identification à deux endroits : dans l'enregistrement de l'application (qui, comme mentionné, est géré par le développeur) et dans le principal du service. Dans le cas d'applications multi-locataires, le principal de service se trouve dans le locataire du client et est sous le contrôle du client, qui peut alors attribuer des informations d'identification au principal de service(Figure 2).

Pour se protéger contre l'attribution ou l'utilisation de secrets sur les principaux de service, les développeurs d'applications peuvent utiliser un mécanisme dans Entra ID appelé app instance property lock (verrouillage de propriété d'instance d'application ). D'après nos recherches et nos discussions avec Microsoft, cette dernière utilise un mécanisme différent qui permet d'obtenir le même résultat : ne pas autoriser l'authentification à l'aide d'un identifiant sur un principal de service.

Qu'un identifiant soit attribué à un enregistrement d'application ou à un principal de service, les deux peuvent être utilisés pour effectuer un flux d'octroi d'identifiant client OAuth 2.0 afin d'agir en tant qu'application dans Microsoft Graph(Figure 3).

Au cours d'un flux d'octroi de justificatifs d'identité d'un client, les étapes suivantes se produisent :

1. L'application utilise son identifiant de client et son justificatif d'identité pour s'authentifier auprès d'Entra ID. Une application est en fait tout ce qui connaît l'identifiant du client, l'identifiant du locataire et le justificatif d'identité. Ainsi, dans le cadre de cet abus, bien que l'application nommée puisse être une application Microsoft, l'application qui agit est l'attaquant.
2. Entra ID valide l'identifiant et le justificatif du client et répond par un jeton d'accès.
3. L'application demande des données à Microsoft Graph, en transmettant le jeton.
4. Microsoft Graph valide le jeton d'accès.
5. Si le jeton est valide, Microsoft Graph fournit les données ou l'action demandées.

Tous les détails de ce flux sont disponibles dans la documentation Microsoft "Microsoft identity platform and the OAuth 2.0 client credentials flow" (Plateforme d'identité Microsoft et flux d'informations d'identification du client OAuth 2.0).

Parce que Microsoft Graph est une API REST, des actions telles que GET peuvent être utilisées pour demander des données à Entra ID, et des actions telles que POST et PATCH peuvent être utilisées pour créer ou modifier des données dans Entra ID.

Si une application a la permission Group.Create qui lui est assignée et que vous avez l'accréditation pour cette application, vous pouvez créer un groupe, et les journaux d'audit d'Entra ID montreront que le groupe a été créé par le principal de service pour cette application.

Supposons par exemple que vous ayez une application tierce nommée Custom Application, que vous utilisez pour accéder à Microsoft Graph via le Microsoft Graph PowerShell SDK. Les informations d'identification transmises en tant que $creds contiennent l'identifiant de l'application et l'information d'identification(figure 4).

Si vous effectuez des actions en utilisant les permissions accordées à cette application - dans ce cas, Group.Create - cesactions apparaissent dans les journaux d'audit d'Entra ID comme ayant été effectuées par l'application. Comme vous pouvez le voir dans la figure 5, l'application est le principal de sécurité responsable de l'opération "Ajouter un groupe".

Agir en tant qu'applications Microsoft

Dans Entra ID, Microsoft a toujours permis aux clients d'attribuer des informations d'identification à la quasi-totalité des principaux services d'application Microsoft. Dans des cas limités, ces informations d'identification peuvent être utilisées dans les flux d'octroi d'informations d'identification du client OAuth 2.0 pour accéder à Microsoft Graph, agissant comme l'application Microsoft au sein du propre locataire du client.

Comme pour l'application personnalisée de l'exemple précédent, nous avons attribué un identifiant au principal de service de l'application Microsoft Device Registration Service. Nous avons ensuite pu nous authentifier et accéder à Microsoft Graph en tant que Device Registration Service(figure 6).

Élever les privilèges par le biais des applications Microsoft

Au cours de nos recherches, nous avons découvert que certains directeurs de services d'application Microsoft étaient autorisés à effectuer certaines actions qui n'étaient pas définies dans la liste des permissions autorisées. En d'autres termes, nous avons été autorisés à effectuer certaines actions privilégiées alors que nous ne semblions pas avoir la permission de le faire.

Dans Microsoft Graph, les autorisations disponibles peuvent être déterminées en examinant les champs d'applicationattribués - leterme OAuth 2.0 pour les autorisations.

Dans l'exemple de la figure 6, vous pouvez voir que les champs d'application sont vides pour le service d'enregistrement des appareils (figure 7). Cela signifie que cette application n'a pas le droit de faire quoi que ce soit par l'intermédiaire de l'API graphique et que nous aurions dû recevoir une réponse 403 non autorisée lors de la tentative d'une action non autorisée.

Pourtant, lorsque nous avons tenté d'effectuer certaines actions privilégiées, nous avons pu le faire. Dans cet exemple, les figures 8 et 9 montrent une tentative réussie d'ajout d'un utilisateur au rôle d'administrateur global en tant que service d'enregistrement des appareils.

Nos conclusions

Nos recherches nous ont permis de découvrir les capacités suivantes pour chacun des services spécifiés. La portée de l'impact est au sein du locataire Entra ciblé.

Viva Engage (Yammer)

La possibilité de supprimer et d'effacer définitivement des utilisateurs, y compris des utilisateurs privilégiés tels que les administrateurs globaux. Le CSEM a classé cette capacité comme une vulnérabilité de gravité moyenne.

Service de gestion des droits de Microsoft

La possibilité de créer des utilisateurs. Le CSEM a classé cette capacité comme étant de faible gravité. L'explication de la faible gravité est que les objets utilisateurs créés ne sont pas privilégiés.

Service d'enregistrement des appareils

La possibilité de modifier l'appartenance à des rôles privilégiés, y compris le rôle d'administrateur global. Le CSEM a classé cette capacité dans la catégorie "gravité importante", élévation de privilèges sous "Identité" (Entra ID).

Utilisation du mécanisme d'élévation et de persistance des privilèges

Toutes nos découvertes sont préoccupantes dans la mesure où elles contournent les contrôles d'autorisation connus. Cependant, la découverte du service d'enregistrement des appareils est le point central de l'élévation des privilèges et de la persistance potentielle d'un attaquant.

Dans un locataire Entra, les administrateurs d'application, les administrateurs d'application cloud, les administrateurs globaux et les utilisateurs assignés en tant que propriétaire d'une application peuvent attribuer des informations d'identification au principal du service.

Les rôles d'administrateur d'application et d'administrateur d'application en nuage sont considérés comme des rôles privilégiés par Microsoft, comme l'indique la documentation "Microsoft Entra built-in roles". Dans de nombreuses entreprises, les intégrations d'applications tierces peuvent fournir d'autres voies d'élévation des privilèges et d'abus si un administrateur d'application ou un administrateur d'application en nuage est compromis, que l'organisation soit consciente ou non de la mise en place de ces voies.

Cependant, dans un nouveau locataire Entra, ni l'administrateur de l'application ni l'administrateur de l'application cloud n'ont les droits nécessaires pour gérer l'attribution des rôles privilégiés.

Il est également important de noter que ces rôles n'ont pas la possibilité de consentir aux autorisations de l'API Microsoft Graph, ce qui est un malentendu courant chez ceux qui travaillent avec Entra ID.

Si un pirate connaissant la faille du service d'enregistrement des appareils compromettait un utilisateur ayant le rôle d'administrateur d'application ou d'administrateur d'application en nuage, il pourrait utiliser cet accès pour accéder au rôle d'administrateur global ou à tout autre rôle souhaité.

Bien qu'il puisse sembler un peu brutal pour un attaquant de persister avec le rôle d'administrateur global, la persistance pourrait être installée avec ces privilèges en créant un nouvel enregistrement d'application et un nouveau principal de service avec des autorisations d'application privilégiées. De même, un pirate pourrait installer de nouvelles autorisations d'application privilégiée dans une application existante à locataire unique ou trouver une application privilégiée existante et installer des informations d'identification supplémentaires. Les organisations qui ne surveillent pas continuellement ces types de changements et qui n'ont pas la maturité nécessaire pour déterminer les opérations connues et malveillantes dans Entra ID ne seront probablement pas conscientes de l'installation d'un accès persistant ou de la modification temporaire de l'attribution des rôles dans Entra ID.

Le correctif et le chaînon manquant caché

Nous apprécions les conversations que nous avons eues avec le CSEM et l'équipe Microsoft Identity au cours de la résolution de nos problèmes. Notre préoccupation portait principalement sur le manque de portée (permission) de notre accès à Microsoft Graph.

Au cours de notre conversation, Microsoft a indiqué qu'il existait d'autres mécanismes d'autorisation dans les coulisses des applications Microsoft. Ces mécanismes nous ont permis d'effectuer les actions décrites dans cet article.

Microsoft a souligné à juste titre que cette capacité n'est donc pas une faille matérielle dans aucun de ses modèles d'autorisation. Toutefois, elle a reconnu qu'à l'extérieur, sur la base de ce que nous pouvons voir et à quoi nous avons accès, les capacités peuvent sembler erronées. Selon Microsoft, les champs d'application d'OAuth 2.0 sont absolus lorsqu'il s'agit d'interagir avec Microsoft Graph, de sorte que, sans connaissance d'autres systèmes d'autorisation, nous ne pouvons que déduire.

En outre, nos recherches ont donné lieu à de nombreux changements de la part de Microsoft, qui ont permis de restreindre davantage la possibilité d'utiliser des informations d'identification sur les applications Microsoft. Microsoft a également mis en place des contrôles qui limitent la possibilité d'utiliser des informations d'identification sur les mandants de service. Nous avons observé que la liste des principaux services pour lesquels nous pouvons nous authentifier n'a cessé de s'amenuiser

Lorsque nous tentons maintenant de nous authentifier en tant que Device Registration Service, nous recevons une erreur de Microsoft Graph(Figure 10).

Détection d'abus antérieurs

Les applications qui sont au cœur de nos conclusions sont susceptibles d'exister dans la plupart des domaines des clients de Microsoft. Nous sommes convaincus que cette faille existe depuis au moins aussi longtemps que ces applications, c'est-à-dire depuis plusieurs années.

Les deux méthodes de détection de cet abus sont les journaux d'audit d'Entra ID et les informations d'identification persistantes sur les applications abusées. Malheureusement, ces deux méthodes ont leurs limites. Les journaux d'audit ne sont utiles que tant qu'ils sont conservés, et un attaquant aurait pu supprimer les informations d'identification sur les applications abusives initiales après avoir installé une persistance supplémentaire.

Si une organisation trouve des données indiquant que des informations d'identification ont été attribuées au service d'enregistrement des appareils ou découvre des données d'audit pour le service d'enregistrement des appareils, elle doit être très préoccupée. Nous ne connaissons aucune raison valable pour que le service d'enregistrement des appareils se voie attribuer des informations d'identification.

Créances persistantes

Vous pouvez utiliser Microsoft Graph pour inspecter les principaux services affectés afin de déterminer si des informations d'identification supplémentaires leur ont été ajoutées.

Pour ces requêtes graphiques, inspectez les résultats pour déterminer si des valeurs ont été définies ou si l'identifiant est renvoyé comme étant nul.

L'identifiant de l'application est une valeur unique au niveau mondial. Ces commandes PowerShell et la requête Microsoft Graph fonctionneront dans n'importe quel locataire d'Entra.

Service d'enregistrement des appareils

Microsoft Graph PowerShell SDK

((Get-MGServicePrincipal -Filter "AppId eq '01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9'").KeyCredentials).count

((Get-MGServicePrincipal -Filter "AppId eq '01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9'").PasswordCredentials).count

Requête Microsoft Graph

https://graph.microsoft.com/v1.0/servicePrincipals(appId='01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9')?$select=keyCredentials,passwordCredentials

Entrées du journal d'audit

Les organisations peuvent examiner les données du journal d'audit d'Entra ID qui correspondent à certains modèles. Notez que la possibilité de rechercher des données d'audit ne sera possible qu'à partir du moment où l'organisation a stocké ces données.

Recherche d'actions par le service d'enregistrement des appareils

AuditLogs

| where parse_json(tostring(InitiatedBy.app)).displayName == "Device Registration Service"

Chasse à l'attribution de secrets au service d'enregistrement des appareils

AuditLogs

| where OperationName == "Add service principal credentials"

| where TargetResources[0].displayName == " Device Registration Service"

Protéger les clients de Semperis

Pour les utilisateurs de Semperis Directory Services Protector ( DSP) ou Purple Knightnous publions un indicateur de sécurité, Suspicious credentials on Microsoft service principal, qui vérifiera et signalera les informations d'identification attribuées aux services d'enregistrement des appareils et à Viva Engage. Dans le cadre d'une approche de la sécurité de l'identité par couches, les organisations peuvent également vérifier leurs journaux d'audit SIEM à la recherche de marqueurs.

Arrêter les attaques visant les applications privilégiées

Les applications privilégiées et leurs principes de service dans Entra ID sont l'un des moyens les plus courants dont disposent les attaquants pour prendre pied et maintenir la persistance dans Entra ID et pour se déplacer dans d'autres domaines du nuage tels que Microsoft 365, Azure, et les applications multicloud et SaaS qui s'intègrent à Entra ID.

L'une des meilleures défenses que les organisations peuvent prendre est de s'assurer que l'administrateur d'application et l'administrateur d'application en nuage sont traités avec autant de privilèges que les administrateurs globaux, et que les meilleures pratiques telles que la séparation des privilèges, les postes de travail à accès privilégié et l'authentification forte résistante à l'hameçonnage sont considérées comme des exigences et non comme des options.

Recherches connexes et remerciements

La recherche dans l'espace des applications Entra ID et des mandants de service n'est pas un concept nouveau. Nos recherches se recoupent avec des recherches similaires menées en 2019 par Dirk-jan Mollema, qui a exploré l'attribution d'informations d'identification à des mandants de service et l'exploitation des autorisations d'application OAuth 2.0 pour exécuter des fonctions qu'un administrateur d'application ne devrait pas être en mesure d'exécuter. Depuis lors, la liste des applications pouvant être utilisées s'est réduite et a encore été réduite en juillet 2024 à la suite de la réponse de Microsoft à nos conclusions.

Divulgation et calendrier

Les découvertes décrites dans ce billet ont été signalées au CSEM comme indiqué dans la chronologie suivante. Comme il s'agit d'une découverte complexe, il a fallu un certain temps pour examiner les résultats avec le CSEM. Nous apprécions la rapidité avec laquelle la découverte du service d'enregistrement des appareils a été résolue et l'engagement de Microsoft à sécuriser davantage ses applications sur la base de notre travail de collaboration.

• Le 11 janvier 2024 : Création des dossiers du CSEM
• 30 janvier 2024 : Le CSEM a fourni une première réponse de faible gravité
• 6 février 2024 : Réponse fournie au CSEM concernant l'attribution de la gravité
• 4 mars 2024 : Le service d'enregistrement des appareils est reclassé en tant que gravité importante.
• 4 mars 2024 : Viva Engage classée comme étant de faible gravité
• 4 mars 2024 : Les services de gestion des droits de Microsoft sont classés comme étant de faible gravité.
• 4 mars 2024 : Le cas de Microsoft Rights Management Services est résolu et clos
• 4 mars 2024 : Le cas du service d'enregistrement des appareils est résolu et clos
• 1er avril 2024 : Viva Engage est reclassé dans la catégorie des maladies de gravité moyenne.
• Le 17 avril 2024 : Envoi d'un premier avis au CSEM concernant la divulgation
• 19 avril 2024 : Le cas de Viva Engage est résolu et clos
• 5 juin 2024 : Envoi du projet d'article de divulgation au CSEM
• 13 juin 2024 : Réunion avec le CSEM concernant les cas et la divulgation
• Le 7 août 2024 : Divulgation publique