Une nouvelle attaque contre le consentement à l'utilisation : L'octroi de consentement caché

Principales conclusions

• Une attaque par consentement de l'application, également connue sous le nom d'attaque par consentement illicite, est un type d'attaque par hameçonnage dans lequel un acteur malveillant obtient l'accès à une application et exploite ensuite les permissions qui ont été accordées à cette application.
• Adi Malyanker, chercheur chez Semperis, a découvert que dans certaines circonstances, un acteur malveillant pouvait utiliser l'autorisation Directory.ReadWrite.All ou DelegatedPermissionGrant.ReadWrite.All au sein de Microsoft Azure pour élever ses privilèges, accéder à des ressources et des données sensibles, lancer une attaque par déni de service (DoS) ou même prendre le contrôle d'un locataire Entra ID.
• Toute organisation qui utilise des applications dans Entra ID pourrait être vulnérable à cette attaque, appelée attaque par consentement caché.
• À la connaissance de Semperis, aucune attaque de ce type n'a été documentée.
• Les chercheurs de Semperis considèrent cette vulnérabilité comme potentiellement grave en raison de la possibilité d'une prise de contrôle d'un locataire d'Entra ID.

Dans Microsoft Azure, l'autorisation Directory.ReadWrite.All a des implications importantes. Cette autorisation permet une multitude d'actions, y compris la modification par l'utilisateur et l'accès à toutes les données du répertoire.

Cela semble-t-il risqué ? Certains ont fait valoir que, lorsqu'elle est utilisée de manière isolée, cette autorisation ne présente aucun risque inhérent. Cependant, mes recherches indiquent qu'un pirate pourrait utiliser l'autorisation Directory.ReadWrite.All (ou DelegatedPermissionGrant.ReadWrite.All ) pour causer de graves dommages dans un environnement Microsoft Entra ID (anciennement Azure AD) ou un environnement hybride Microsoft Active Directory/Entra ID.

Qu'est-ce que les autorisations d'utilisation ?

Dans Entra ID, les permissions d'application accordent à une application spécifique la possibilité d'effectuer certaines actions ou d'accéder à certaines ressources au sein d'Entra ID ou d'autres services Microsoft. Contrairement aux autorisations déléguées, que les utilisateurs accordent aux applications autorisées, les autorisations d'application sont généralement accordées par un administrateur au cours du processus d'enregistrement de l'application.

L'application utilise ensuite ces autorisations pour effectuer des tâches au nom de l'organisation ou de ses utilisateurs, sans avoir besoin du consentement individuel ou permanent de l'utilisateur(figure 1).

Les autorisations d'application sont souvent utilisées lorsque l'application doit accéder à des ressources ou effectuer des actions qui ne dépendent pas de l'identité ou des autorisations d'un utilisateur spécifique. Voici quelques exemples d'autorisations d'application :

• Lecture des profils d'utilisateurs
• Gestion des groupes
• Accès aux données de l'organisation

Il est essentiel de gérer et d'attribuer avec soin les autorisations d'utilisation des applications. Les organisations doivent s'assurer que les applications ont le niveau d'accès approprié tout en maintenant les normes de sécurité et de conformité dans l'environnement Entra ID.

Qu'est-ce que Directory.ReadWrite.All ?

En recherchant les autorisations d'application, j'ai rencontré l'autorisation Directory.ReadWrite.All. Selon la documentation de Microsoft :

"Directory.ReadWrite.All accorde un accès largement équivalent à celui d'un administrateur de locataire global. Les applications qui bénéficient de l'accès Directory.ReadWrite.All peuvent gérer l'ensemble des ressources de l'annuaire et gérer l'autorisation d'accès aux ressources pour d'autres applications et utilisateurs dans l'ensemble de l'organisation. Cela inclut les ressources de l'annuaire comme les utilisateurs, les groupes, les applications et les appareils, ainsi que les ressources non répertoriées dans Exchange, SharePoint, Teams et d'autres services".

Compte tenu du nom de cette autorisation, de son association avec Entra ID et de son implication dans la gestion des répertoires, j'ai soupçonné que cette autorisation était potentiellement dangereuse.

Mais dans un premier temps, après avoir examiné les actions permises par Directory.ReadWrite.All, je n'ai pas trouvé de menaces notables. D'autres semblent avoir tiré une conclusion similaire. Par exemple, un excellent article publié par SpectreOps affirme que cette autorisation, bien que puissante lorsqu'elle est combinée à d'autres autorisations, n'est pas susceptible de présenter un risque significatif en soi.

J'ai tout de même décidé d'y regarder de plus près.

J'ai commencé à tester ce que l'autorisation Directory.ReadWrite.All pouvait faire à un niveau élevé. Qu'est-ce qu'un acteur malveillant pourrait accomplir en utilisant uniquement cette permission d'application ?
La bonne nouvelle est que je n'ai pas pu utiliser la permission pour faire ce qui suit :

• Ajouter des secrets aux applications
• Ajouter des propriétaires
• Ajouter des membres ou des propriétaires avec un rôle à un groupe de sécurité
• Attribuer un rôle à une application
• Réinitialiser le mot de passe d'un utilisateur

Ces appels à l'API ont renvoyé une réponse comme celle de la figure 2.

Cependant, j'ai pu utiliser Directory.ReadWrite.All pour faire ce qui suit :

• Ajouter un nouveau membre ou propriétaire sans rôle assigné à un groupe de sécurité
• Ajouter des utilisateurs au répertoire
• Modifier les consentements des administrateurs
• Modifications limitées aux unités administratives

Remarque : plus de 400 appels API sont consacrés à Teams, aux appareils et à OneDrive. Ces appels dépassent le cadre de cette étude.

Des actions telles que l'ajout de nouveaux utilisateurs et membres, qui n'ont pas de rôle assigné, à des groupes pourraient être très utiles aux attaquants qui tentent d'obtenir un accès initial à un répertoire ou à des ressources. Cette possibilité est suffisamment préoccupante, mais je me demandais s'il était possible d'aller plus loin.

Puis-je utiliser l'autorisation Directory.ReadWrite.All pour me transformer en administrateur global ?

Directory.ReadWrite.All peut-il constituer un vecteur d'attaque potentiel ?

Avant de passer aux choses sérieuses, une remarque : le jeton d'accès qui vous permet de vous connecter à Azure contient un champ spécial appelé champ d'application ou scp. Ce champ indique les autorisations accordées à l'utilisateur(figure 3).

J'ai vérifié cette valeur tout au long de mes recherches pour déterminer si mes tentatives d'élévation des autorisations avaient abouti.

Pour tester mes soupçons concernant Directory.ReadWrite.All, j'ai choisi une API Microsoft Graph, oauth2PermissionGrant, qui peut créer une autorisation déléguée sur une ressource pour une entité choisie(figure 4).

Pour effectuer cet appel à l'API, je devais accorder à une application l'autorisation Directory.ReadWrite.All(figure 5). J'ai opté pour postman-test(Figure 6).

J'ai également créé un compte utilisateur faible, Evil User(Figure 7), pour représenter un attaquant (qui simule un utilisateur malveillant membre du locataire et un utilisateur légitime obtenu par un attaquant). Je n'ai accordé à cet utilisateur aucun rôle ni aucune autorisation(figure 8).

Pour invoquer les appels de l'API, j'ai connecté le principe de service postman-test avec Postman. Passons en revue les propriétés et les exigences de l'API(figure 9):

• clientId identifie l'application (dans ce cas, Graph Explorer) qui est autorisée à agir au nom d'un utilisateur connecté. La valeur clientId remplace l'identité de l'utilisateur.
• consentType indique si l'application client est autorisée à usurper l'identité de tous les utilisateurs ou seulement d'un utilisateur spécifique.
• resourceId spécifie la ressource (dans ce cas, Microsoft Graph) à laquelle le clientId peut accéder avec les autorisations accordées.
• définit les actions spécifiques (par exemple, device.Read.All, Director.ReadWrite.All) que l'identifiant du client peut effectuer sur l'identifiant de la ressource.

Pour résumer les relations entre ces propriétés : Un ou plusieurs utilisateurs accordent à l'IDClient un ensemble de permissions approuvées, telles que définies par le champ d'application. L'identifiant client peut alors utiliser ces autorisations pour accéder à l'identifiant ressource spécifié.

Revenons maintenant à l'exploration de mon appel API. Tout d'abord, j'ai besoin de l'ID de l'objet Graph Explorer. Je peux soit naviguer dans le portail d'applications d'Azure, soit utiliser l'API Graph(figure 10) pour obtenir cet identifiant.

Pour commencer, j'ai utilisé Graph Explorer comme clientId et resourceId.

En tant que Evil User, j'ai essayé de lire tous les groupes du répertoire. Comme vous pouvez le voir dans la réponse 403 de la figure 11, cette action n'a pas été autorisée en raison de privilèges insuffisants.

Ensuite, j'ai essayé d'ajouter une autorisation déléguée - GroupMember.Read.All - àGraph Explorer pour l'ensemble du répertoire(Figure 12). Si j'y parvenais, tous les utilisateurs du répertoire (y compris Evil User) devraient se voir accorder cette autorisation.

J'ai vérifié que l'ajout de cette autorisation avait été effectué avec succès. Notez que dans l'application Graph Explorer, la permission a été accordée pour l'ensemble du répertoire(Figure 13).

Je devrais maintenant pouvoir utiliser l'appel API pour obtenir tous les groupes(figure 14).

Bizarre...Graph Explorer avait la permission GroupMember.Read.All avec le consentement de l'administrateur, mais je reçois toujours une réponse 403. Pourquoi ?

Vous vous souvenez de la définition des autorisations déléguées ? Comme Graph Explorer utilise les autorisations de l'utilisateur connecté, il ne peut lire les membres que si l'utilisateur connecté a le rôle ou le niveau de privilège adéquat pour utiliser cette autorisation, ce qui n'est pas le cas de Evil User. Ma tentative s'est soldée par une impasse.

Mais attendez. Connaissez-vous l'attaque de la subvention pour consentement illicite ?

Qu'est-ce qu'une attaque au moyen d'une subvention pour consentement illicite ?

En termes simples, une attaque par consentement illicite, également connue sous le nom d'attaque par consentement d'application, se produit lorsqu'une personne est incitée à accorder à une application tierce (c'est-à-dire externe) des droits excessifs sur ses données ou sur la configuration de ses applications Office 365. La figure 15 illustre le fonctionnement de cette attaque.

En bref, un attaquant crée une application enregistrée dans Azure. Ensuite :

1. L'application demande l'accès à des données sensibles telles que des informations de contact, des courriels ou des documents.
2. L'utilisateur final donne son accord à l'application. Le consentement peut être obtenu par des attaques de phishing ou par l'injection d'un code illicite dans un site web de confiance.
3. L'application de l'attaquant reçoit une autorisation et un jeton d'accès.
4. L'application malveillante - et l'attaquant - ont désormais accès aux données de l'utilisateur au niveau du compte.

Que se passerait-il si un attaquant lançait une attaque par consentement illicite, en utilisant une application malveillante ayant obtenu l'autorisation Directory.ReadWrite.All? Il était temps de retenter l'expérience.

Rencontre avec l'attaque cachée de la bourse du consentement

Cette fois, j'ai joué le rôle d'un attaquant tentant de compromettre un utilisateur dans le répertoire cible par le biais d'une application disposant de l'autorisation Directory.ReadWrite.All. L'application démarrait avec des privilèges faibles, puis augmentait ses autorisations après avoir reçu le consentement de l'administrateur(Figure 16).

Ce flux d'attaque serait possible en utilisant une application, mais j'ai décidé d'utiliser deux applications pour plus de discrétion (en séparant l'application avec la permission Directory.ReadWrite.All et l'application dont les permissions seront mises à jour). Pour cette expérience :

1. J'ai créé un compte pour un utilisateur aux privilèges limités : Harmless Attacker (harmless_attacker). Cette expérience suppose qu'un attaquant a déjà obtenu l'accès à ce compte par le biais d'un hameçonnage, d'une autre attaque ou d'une adhésion au locataire.
2. J'ai créé un compte d'utilisateur privilégié, Privileged User (privileged_user), pour représenter un administrateur global.
3. J'ai utilisé Harmless Attacker pour créer une application avec la permission Directory.ReadWrite.All (dans ce cas, postman-test, que j'ai utilisé pour accorder des permissions déléguées à 365stealer).
4. J'ai utilisé Harmless Attacker pour créer une autre application, appelée 365stealer. Cette application présente les paramètres illustrés à la figure 17. Notez que l'URI de redirection de l'application mène à un point de terminaison contrôlé par l'attaquant.

Harmless Attacker n'a pas pu ajouter d'autorisations privilégiées à l'application 365stealer lors de sa création, si bien qu'au départ, les autorisations de l'application ressemblaient à celles de la figure 18.

Ensuite, j'ai utilisé un point de terminaison contrôlé par l'attaquant pour mettre en place un serveur HTTPS, écoutant sur le port 443(Figure 19).

J'ai ensuite utilisé Harmless Attacker pour créer une page de phishing(figure 20). Dans un scénario réel, Harmless Attacker tenterait d'inciter l'utilisateur privilégié à accéder à cette page par le biais d'un courrier électronique ou d'un fichier malveillant.

La page d'hameçonnage contenait un lien hypertexte vers une page de connexion Microsoft redirigée, où l'utilisateur privilégié sera encouragé à se connecter à l'application malveillante(365stealer). Selon la partie redirect_uri, les jetons seront envoyés au serveur HTTPS déployé par l'attaquant(figure 21).

Après avoir réussi à se connecter, l'utilisateur se voit proposer une demande de consentement(figure 22).

Rien dans ces autorisations ou dans la demande de consentement ne semble préjudiciable (aucune autorisation sensible n'est requise), de sorte que l'utilisateur acceptera le consentement. Dans notre cas, il se verra présenter une page comme celle de la figure 23, fermera son navigateur et poursuivra sa journée.

Note : Même si la page est marquée comme non sécurisée, il existe des moyens de la contourner. Cependant, cela dépasse le cadre de cet article. Vous pouvez également voir la note non vérifiée dans le consentement. J'aborderai les moyens de la masquer plus loin dans l'article.

Pendant ce temps, à l'insu de l'utilisateur, l'attaquant recevra le jeton d'accès et l'utilisera pour appeler l'API /me(figure 24).

Ce jeton d'accès contient les autorisations que l'utilisateur a acceptées lors de la demande de consentement. Un coup d'œil au champ scp du jeton le confirme(figure 25).

Ainsi, l'attaquant dispose maintenant d'un jeton d'accès (et d'un jeton de rafraîchissement) d'un utilisateur privilégié. Mais ce jeton ne peut être utilisé qu'avec l'application et les permissions déléguées listées dans le champ d'application. L'attaquant n'a toujours pas la permission RoleManagement.ReadWrite.Directory, donc toute tentative d'appeler l'API directoryRoles (via une requête à https://graph.microsoft.com/v1.0/directoryRoles) renverra une réponse Access Denied(Figure 26).

Là encore, il semble que le potentiel de nuisance de l'attaquant soit très limité. Comment un attaquant pourrait-il escalader ses privilèges et appeler d'autres API intéressantes ?

C'est là que Directory.ReadWrite.All intervient.

Pourrais-je utiliser l'API oauth2PermissionGrant de mon expérience originale, qui ne requiert que la permission Directory.ReadWrite.All, et l'utiliser pour accorder la permission déléguée RoleManagement.ReadWrite.Directory à l'application 365stealer ?

Pour le savoir, j'utilise d'abord l'API oauth2PermissionGrant pour énumérer le clientId et le resourceId utilisés pour 365stealer(Figure 27).

Ensuite, j'ai défini le type de consentement sur "Tous les directeurs"(Figure 28). Cela supprime l'obligation d'obtenir le consentement de l'administrateur lors de l'octroi des autorisations.

Attendez un instant. L'autorisation RoleManagement.ReadWrite.Directory a été accordée mais ne figure pas dans la liste des autorisations configurées(Figure 29).

L 'attaquant inoffensif possède l'application 365stealer . Il me suffit de cliquer avec le bouton droit de la souris sur RoleManagement.ReadWrite.Directory et de sélectionner Add to configured permissions (Figure 30). Même sans cette étape, la permission devrait toujours être disponible pour moi.

L'autorisation est maintenant configurée(Figure 31).

Il me suffit maintenant d'appeler le point de terminaison /refresh du serveur HTTP pour actualiser le jeton d'accès du compte de l'utilisateur privilégié et mettre à jour ses autorisations(figure 32).

Un examen de la portée du jeton permet de vérifier l'ajout de l'autorisation RoleManagement.ReadWrite.Directory(Figure 33).

Avec cette autorisation dans le jeton d'accès, je peux maintenant appeler GET https://graph.microsoft.com/v1.0/directoryRoles(Figure 34).

Je peux maintenant appeler POST https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments pour attribuer à Harmless Attacker le rôle Global Admin(Figure 35).

C'est fait ! Un coup d'œil aux affectations actives du compte de l'attaquant confirme l'escalade des privilèges(figure 36). Ma tentative de lancer ce que j'ai appelé un Hidden Consent Grant a été couronnée de succès.

La subvention cachée du consentement : Maintenant avec plus de discrétion !

Vous vous souvenez de la demande de consentement présentée à l'utilisateur, lors des premières étapes de l'attaque "Hidden Consent Grant" ? Je me suis demandé si je pouvais cacher ce défi pour rendre l'attaque encore plus furtive. Cela créerait un flux d'attaque similaire sans nécessiter d'action de la part de l'utilisateur sous la forme d'un défi de consentement de la victime, même lorsque l'application demande des autorisations élevées(Figure 37).

J'ai commencé avec les mêmes autorisations que celles utilisées lors de l'expérience précédente. Cependant, j'ai accordé à l'application 365stealer un consentement administratif(Figure 38). N'oubliez pas que Directory.ReadWrite.All permet à l'attaquant d'agir sans aucune interaction avec l'utilisateur.

Il s'agit maintenant d'exécuter le flux d'hameçonnage et de déterminer si l'utilisateur privilégié est confronté à une demande de consentement lorsqu'il clique sur le lien de la page d'hameçonnage. (Attention : ce n'est pas le cas).

À ce stade, j'ai prouvé deux choses :

• La victime de l'hameçonnage ne sera pas confrontée à un défi de consentement si les privilèges requis ont déjà été approuvés par l'administrateur.
• Même après que l'administrateur a approuvé le défi de consentement pour l'ajout des autorisations de l'application, l'attaquant peut ajouter des autorisations supplémentaires en modifiant manuellement les autorisations, à l'insu de la victime.

Diffusion de la subvention pour le consentement caché

Je me suis demandé si je pouvais transformer toutes les applications du répertoire pour qu'elles servent de liens d'hameçonnage. Je savais que je pouvais transformer toutes les applications que nous possédions en applications de phishing en modifiant leur URL de redirection. Mais qu'en est-il des applications qui ne répondent pas à cette exigence ?

Dans les rares cas où une application dispose également de l'autorisation Application.ReadWrite.All, l'attaquant peut modifier ou ajouter une autre URL de redirection - le serveur d'écoute de l'attaquant - à l'application. De cette façon, chaque application du répertoire est transformée en une entité malveillante(Figure 39).

L'appel à l'API graphique illustré dans la figure 40 peut aider à modifier l'URI de redirection de l'application(figure 41).

Pour ce vecteur d'attaque, l'attaquant doit toujours connaître le secret de l'application. Heureusement pour lui, Application.ReadWrite.All lui permet d'ajouter un nouveau secret à l'application(Figure 42).

Remarque : il semble y avoir une divergence entre la documentation de Microsoft et mes propres observations. D'après mes tests, bien que Directory.ReadWrite.All soit mentionné, des autorisations supplémentaires peuvent être nécessaires.

Pour cette preuve de concept, Semperis a construit et publié un nouvel outil, HiddenConsentGrant, disponible ici. Cet outil peut être utilisé pour créer un serveur d'écoute, qui attend les réponses des jetons d'accès.

Détection et mesures d'atténuation

Comment repérer une attaque de type "Hidden Consent Grant" ?

1. Les utilisateurs de Semperis Directory Services Protector ( DSP) ou Purple Knight pourront utiliser l'indicateur de sécurité Entra tenant is susceptible to Hidden Consent Grant Attack pour vérifier et signaler la possibilité d'une attaque par consentement caché sur le locataire.
2. Recherchez des chefs de service suspects dotés de privilèges élevés, tels que Rolemanagement.ReadWrite.Directory, Application.ReadWrite.Allet AppRoleAssignment.ReadWrite.All. Vous pouvez utiliser l'appel API suivant pour énumérer ces autorisations (Figure 43) :
   GET graph.microsoft.com/v1.0/oauth2PermissionGrants?$filter=consentType eq %27AllPrincipals%27
   

   

3. Déterminez si un administrateur a approuvé les autorisations.
4. Vérifiez que les autorisations sont activement utilisées et requises.
5. Supprimer les privilèges inutiles.
6. Dans les journaux d'audit, recherchez l'élément Ajouter une autorisation déléguée avec l'acteur initié Application (Figure 44).
   

   

   Les Type doit être Application et le Type d'activité devrait être Ajouter une autorisation déléguée. Vous pouvez utiliser l'API graphique pour obtenir tous les journaux d'audit qui ont le type d'activité Ajouter une autorisation déléguée:
   https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?$filter=activityDisplayName eq 'Add delegated permission grant'

   Vous pouvez alors rechercher "user" : null, ce qui signifie qu'une application a invoqué l'octroi de la permission déléguée(Figure 45).

   

7. Contrôler et révoquer toute personne non autorisée OAuth de consentement. L'appel API suivant peut vous aider :
   GET https://graph.microsoft.com/v1.0/oauth2PermissionGrants/
   Cet appel renvoie toutes les autorisations déléguées accordées dans le locataire, le type d'autorisation et l'entité (Figure 46).
   

   

8. Enfin, évitez de donner aux applications les autorisations Directory.ReadWrite.All ou DelegatedPermissionGrant.ReadWrite.All. (La permission DelegatedPermissionGrant.ReadWrite.All permet à un attaquant de lancer les mêmes attaques que celles que je décris dans cet article). Dans la mesure du possible, configurez des autorisations plus spécifiques pour vos applications.

Faire la lumière sur les subventions cachées au titre du consentement

Cet article illustre la preuve de concept de plusieurs flux d'attaques qui abusent du rôle Directory.ReadWrite.All pour obtenir potentiellement toutes les autorisations qu'un attaquant pourrait souhaiter. Ces flux d'attaque pourraient être mortels entre les mains d'un attaquant avisé. Révisez et renforcez les permissions de vos applications dès maintenant et fermez cette ouverture potentielle avant que les acteurs de la menace n'en tirent parti.