Augmentation des privilèges dans Entra ID (anciennement Azure AD)

Les attaques par escalade de privilèges sont l'un des problèmes les plus urgents pour les équipes de sécurité du monde entier et sont couramment utilisées dans le cadre de mouvement latéral. Les auteurs de menaces savent que les comptes privilégiés sont plus difficiles à compromettre car ils sont généralement surveillés et protégés. Cependant, les attaquants peuvent utiliser des vulnérabilités d'escalade de privilèges pour prendre le contrôle de comptes moins surveillés et se donner par la suite un niveau d'accès élevé, tout en restant sous le radar de l'équipe de sécurité.

Dans l'environnement hybride d'aujourd'hui, les entreprises transfèrent de plus en plus leurs ressources sensibles vers des applications SaaS. Azur Active Directory est l'un des principaux fournisseurs d'identité cloud qui permet aux entreprises de gérer de manière centralisée l'accès et l'utilisation de ces applications.

Nous avons récemment découvert un problème d'élévation de privilèges au sein de Entra ID (anciennement Entra ID) qui pourrait permettre à un attaquant de contourner une protection de réinitialisation de mot de passe, permettant ainsi aux administrateurs de niveau inférieur de devenir des administrateurs pleinement privilégiés. Nous avons signalé ce problème au Microsoft Security Response Center (MSRC), qui l'a validé et appliqué un correctif. Même si cela ne présente plus de risque pour Entra ID (anciennement Azure AD), nous pensons que la communauté de la sécurité au sens large peut bénéficier de notre analyse et de nos résultats.

Analyse technique

La Entra ID (anciennement Azure AD) fonctionne comme une hiérarchie, empêchant les administrateurs moins privilégiés de réinitialiser le mot de passe des administrateurs plus privilégiés. En plus de la logique opérationnelle, cela protège également contre un scénario dans lequel un compte administrateur avec des privilèges inférieurs est compromis en garantissant que l'attaquant ne peut pas modifier ceux avec des privilèges plus élevés.

Cette garantie s'applique lorsque le rôle de l'utilisateur est défini sur « éligible » ou « actif ». Cependant, Entra ID (anciennement Azure AD) permet également des comptes d'utilisateurs ou administrateurs à attribuer pour usage futur; c'est-à-dire que les privilèges de niveau supérieur sont accordés à une date et une heure prédéfinies.

Nous avons découvert que dans ce cas, la protection par mot de passe ne s'applique pas. Cela expose Entra ID (anciennement Azure AD) au scénario suivant :

1. Compromis initial: Un attaquant compromet un compte admin avec de faibles privilèges.
2. Découverte des futures attributions de rôles: L'attaquant scanne Entra ID (anciennement Azure AD) pour rechercher les comptes qui devraient devenir des administrateurs hautement privilégiés à l'avenir.
3. Réinitialiser le mot de passe: L'attaquant réinitialise maintenant le mot de passe de ces comptes, les compromettant avant que l'attribution des rôles n'ait lieu. Idéalement, l'attaquant effectuerait cette réinitialisation le plus près possible de l'heure du changement de rôle.
4. Elévation de privilèges: Le changement de rôle a lieu, offrant à l'attaquant un contrôle total sur un compte administrateur actif hautement privilégié.

Passons en revue ces étapes une par une :

Compromis initial

Aux fins de cette analyse, supposons que cela a déjà eu lieu. L'attaquant a compromis le compte de "Shay Katz", qui a une affectation active de "Helpdesk Administrator".

Capture d'écran 1 : Écran des rôles attribués à Shay Katz

Le tableau suivant, tiré de Entra IDLa page Web de rôle intégrée de (anciennement Azure AD) affiche les droits de réinitialisation de mot de passe de divers rôles au sein de Entra ID (anciennement Azure AD). Nous pouvons voir que « Administrateur du Helpdesk » ne peut pas réinitialiser les mots de passe des rôles « Administrateur d'authentification » et « Administrateur de mots de passe ».

Capture d'écran 2: Entra ID (anciennement Azure AD) tableau des autorisations de réinitialisation de mot de passe

L'attaquant est désormais connecté à Entra ID (anciennement Azure AD) en tant qu'utilisateur « Shay Katz ».

Découverte des futures attributions de rôle

Avant le correctif de Microsoft, il existait deux options pour découvrir les futures missions d'administrateur à moindre coût. utilisateurs privilégiés:

1. Avec Entra ID (anciennement Azure AD), en consultant la page « Demande en attente » pour une future attribution de rôle d'un administrateur de niveau supérieur.
2. Via un script, en utilisant le Resource Graph.

a) Autorisations requises :

Répertorier les demandes d'éligibilité aux rôles planifiés : Nécessite : ReadWrite.AzureAD

Une liste avec :

1. DeviceManagementApps.Read.All
2. DeviceManagementApps.ReadWrite.All
3. Répertoire.Lire.Tout
4. Répertoire.ReadWrite.All
5. Utilisateur.Lire.Tout
6. Utilisateur.ReadBasic.All
7. Utilisateur.ReadWrite.All

b) Exécutez la requête « https://graph.microsoft.com/beta/roleManagement/directory/roleEligibilityScheduleRequests » pour obtenir la demande planifiée.
Filtrer sur status = 'provisioned' AND scheduleInfo['startDateTime'] > currentTime AND roleDefinitionId dans protectedRoleIdList.

c) Exécutez la requête « https://graph.microsoft.com/beta/users?$select=displayName,id » pour obtenir le nom d'affichage de l'utilisateur à l'aide de la clé principalId.

Le Entra ID (anciennement Azure AD) (option A), l'attaquant découvre un exemple de compte de test qui n'a actuellement aucune attribution de rôle « Actif » ou « Éligible ».

Capture d'écran 3 : Compte "Test" sans devoirs "éligibles" ou "actifs"

Cependant, les champs "Heure de la demande" et "Heure de début" nous montrent que ce compte de test a une demande en attente pour être ajouté en tant qu'administrateur global à l'avenir.

Capture d'écran 4 : demande en attente pour que le compte de test devienne administrateur général

L'attaquant a maintenant trouvé une cible digne de ce nom : un compte à faibles privilèges avec une future attribution de rôle. Nous pouvons maintenant passer à l'étape suivante.

Réinitialiser mot de passe

L'attaquant peut désormais réinitialiser le mot de passe du compte de test à l'aide du Entra ID (anciennement Azure AD) :

Capture d'écran 5 : Réinitialisation du mot de passe pour le compte de test

Elévation de Privilèges

Mission accomplie. Lorsque l'heure de début définie arrive, le compte de test sera mis à niveau vers un compte d'administrateur général - et l'attaquant aura le contrôle total.

Le correctif de Microsoft

Microsoft a résolu le problème en implémentant les contrôles suivants :

• Un administrateur à faibles privilèges ne peut plus voir les demandes en attente dans le portail.
• Si vous essayez de réinitialiser le mot de passe pour une future attribution de rôle privilégié, vous rencontrez une erreur. (Généralement, si vous n'êtes pas autorisé à réinitialiser un mot de passe, le bouton de réinitialisation du mot de passe est verrouillé.)

Conclusion

Comme indiqué, Microsoft a résolu ce problème, cette technique d'attaque n'est donc plus efficace. Il convient toutefois de noter que ces types de problèmes liés aux protections d’accès juste à temps sont connus pour attirer les attaquants. Dans ce cas, il y avait un écart entre l’attribution du privilège et l’activation réelle d’une mesure de sécurité conçue pour le protéger. À mesure que les entreprises s'orientent de plus en plus vers le cloud, la volonté des acteurs malveillants de rechercher de telles faiblesses dans l'infrastructure de gestion SaaS augmente. Nous sommes heureux d'avoir eu cette opportunité d'atténuer une exposition dans le surface d'attaque et souhaitons remercier Microsoft pour sa réponse efficace et rapide.