Active Directory (AD) est un produit Microsoft conçu pour aider les administrateurs réseau à gérer les autorisations des utilisateurs au sein d'une organisation. Il est installé sur un serveur Windows, le transformant en contrôleur de domaine chargé de gérer les environnements d'entreprise et d'effectuer des actions telles que le stockage de tous les des comptes d'utilisateurs ou administrateurs, leurs mots de passe et leurs autorisations, et la gestion de l'authentification des utilisateurs.
Au fil du temps, le monde évolue de plus en plus vers l'adoption du cloud, et Microsoft a également poussé les organisations à se tourner vers des environnements basés sur le cloud pour des processus plus rationalisés et plus modernes. gestion de l'identitéLa solution de Microsoft pour l'environnement de domaine basé sur le cloud est Entra ID. Il étend les capacités d'AD sur site au cloud, offrant une solution robuste pour la gestion des identités et des accès pour les applications basées sur le cloud. Pour permettre une intégration transparente avec les systèmes existants pris en charge, Microsoft a introduit Entra ID Connecter. Cet outil permet aux organisations de relier leurs locaux Active Directory (AD) environnement avec Entra ID, créant un « environnement hybride joint ».
Avec Entra ID Connect permet aux organisations de synchroniser les utilisateurs et les données d'annuaire de leur AD sur site vers le cloud. Cela permet aux utilisateurs d'accéder aux services cloud tout en utilisant les mêmes informations d'identification que pour leurs systèmes sur site. Une fonctionnalité intéressante Entra ID Connect prend en charge la réécriture des mots de passe, où les modifications de mot de passe effectuées dans le cloud sont synchronisées avec l'AD sur site, garantissant ainsi une gestion cohérente des identités dans les deux environnements. Ce modèle hybride garantit que les organisations peuvent maintenir un système d'identité unifié tout en opérant sur les infrastructures cloud et sur site.
Les différences dans la gestion des autorisations entre les systèmes hérités Active Directory et Entra ID peut entraîner des failles de sécurité dans le processus de synchronisation entre les deux produits.
Plongée en profondeur dans la gestion des autorisations
Gestion des autorisations dans Active Directory fonctionne de telle manière que dans chaque environnement, il existe plusieurs groupes de sécurité privilégiés par défaut avec des autorisations élevées pour effectuer des modifications. Lorsque nous voulons accorder ces autorisations à un utilisateur spécifique, nous l'ajoutons simplement au groupe. Par exemple, le groupe « Administrateur de domaine » accorde des privilèges à tous les utilisateurs qui le composent. Une autre méthode pour définir les autorisations des utilisateurs ou des groupes consiste à utiliser l'ACL (Access Control List). Cette liste existe pour chaque objet dans AD et spécifie les autorisations pour chaque entité. Ce mécanisme permet d'attribuer des autorisations à un utilisateur ordinaire pour effectuer des modifications, même à des objets appartenant à des utilisateurs avec des privilèges de haut niveau, tels que les administrateurs de domaine.
Cependant, dans Entra ID (anciennement Azure AD), il n'existe pas de groupes de sécurité par défaut. Au lieu de cela, il utilise un mécanisme RBAC (Role-Based Access Control). Cela signifie qu'il existe de nombreux types de rôles, chacun définissant des autorisations utilisateur différentes. Vous pouvez également attribuer un rôle à un groupe, et tous les membres de ce groupe hériteront des mêmes autorisations. Mais cette option n'inclut pas les groupes définis par défaut, comme Active Directory.
Alors, quelle est la différence entre les deux mécanismes ? Dans Entra, une protection contre les modifications est fournie lorsqu'un utilisateur reçoit des autorisations privilégiées par attribution de rôle ou de groupe. Dans l'ancien AD, nous avons découvert que tous les groupes sensibles ne sont pas protégés contre les modifications. En fait, certains groupes sensibles sont traités comme faibles en ce qui concerne Entra ID Connectez la synchronisation.
Dans Entra, chaque fois qu'un utilisateur reçoit un rôle privilégié, il bénéficie automatiquement d'une protection contre les modifications. Seul un utilisateur disposant de privilèges de niveau supérieur ou d'un niveau de rôle équivalent peut effectuer des modifications, ce qui empêche tout autre utilisateur disposant d'un niveau de rôle inférieur de le faire. Cela signifie que l'utilisateur n'a pas besoin d'être membre d'un groupe de sécurité pour être protégé : il suffit de lui attribuer un rôle privilégié pour lui fournir un certain niveau de protection, contrairement à AD.
Par exemple, dans la hiérarchie de rôles d'administrateur dans les Entra ID, le Administrateur de mot de passe Le rôle accorde aux utilisateurs la possibilité de réinitialiser les mots de passe. Cependant, bien qu'il soit classé comme administrateur, ce rôle est considéré comme l'un des plus bas dans la hiérarchie des administrateurs. Par conséquent, les administrateurs de mots de passe ne peuvent réinitialiser les mots de passe que pour utilisateurs réguliers ou les utilisateurs détenant le même rôle d'administrateur. Ils n'ont pas l'autorité pour réinitialiser les mots de passe des utilisateurs de niveau supérieur rôles d'administrateur, tels que les administrateurs globaux ou autres comptes privilégiés, en maintenant une limite de sécurité claire entre les différents rôles d'administrateur. Cette structure hiérarchique garantit que les rôles les plus sensibles sont protégés contre les modifications de mot de passe non autorisées.
Comment se produit la synchronisation ?
Le processus de synchronisation entre AD sur site et Entra ID peut être divisé en deux parties principales :
- Synchronisation des identités depuis les locaux vers Entra ID
- Réécriture du mot de passe à partir de Entra ID sur site
Partie 1 : Synchronisation depuis les locaux vers Entra ID
Entra ID Connect crée un compte de service L'utilisateur a appelé MSOL après les 8 premiers octets de l'identifiant d'installation. Cet utilisateur dispose de fonctionnalités puissantes qui peuvent être équivalentes à celles d'un contrôleur de domaine. L'autorisation « Réplication de toutes les modifications de l'annuaire » permet à l'utilisateur d'effectuer une synchronisation DC et d'extraire tous les attributs de l'objet, y compris les informations d'identification du client, en d'autres termes, son hachage NT. En raison des autorisations étendues accordées à cet utilisateur dans l'annuaire, il peut accéder aux informations sur les utilisateurs des groupes protégés et les lire. En effet, les autorisations fournies permettent à l'utilisateur d'opérer avec des privilèges de type contrôleur de domaine. Par conséquent, même si l'utilisateur n'est pas explicitement répertorié dans la liste de contrôle d'accès d'un groupe, il conserve la possibilité de récupérer le hachage NT des membres du groupe. Cette autorisation autorise le côté local du processus de synchronisation et est gérée à l'aide du protocole distant du service de réplication d'annuaire, qui fonctionne sur le transport RPC. Le même protocole est utilisé pour effectuer l'attaque DCSync. L'agent de synchronisation sur site envoie toutes les informations et tous les attributs de l'utilisateur à Entra ID via le port 443. Une fois qu'Entra reçoit ces données, il les traite et renseigne les détails nécessaires dans son environnement, complétant ainsi le processus de synchronisation initial.
Partie 2 : Réécriture du mot de passe à partir de Entra ID sur site
La deuxième partie du processus de synchronisation a lieu lorsque la fonction de réécriture du mot de passe est activée dans Entra AD Connect. Cette fonctionnalité permet la synchronisation des mots de passe du cloud vers l'environnement sur site. Ainsi, lorsqu'un utilisateur modifie son mot de passe dans le cloud, la modification est également répercutée sur site. Cela garantit une synchronisation précise entre les deux environnements, ce qui est l'une des principales raisons de les connecter : permettre aux utilisateurs de se connecter avec le même mot de passe dans toutes les applications et tous les environnements de l'organisation.
Lorsqu'une action de réinitialisation de mot de passe est lancée pour un utilisateur dans Entra ID, le système recherche d'abord le nom d'utilisateur pour vérifier qu'il existe dans Entra ID. Si l'utilisateur est découvert, une vérification des autorisations est effectuée pour voir si la personne qui tente de réinitialiser le mot de passe dispose d'un rôle qui lui permet d'effectuer cette action. Si l'utilisateur dispose des autorisations nécessaires, Entra ID envoie le nom d'utilisateur et le nouveau mot de passe au bus de service Entra.
L'agent de synchronisation exécuté sur site récupère ces informations. Étant donné que l'utilisateur MSOL créé par Entra Connect dispose des autorisations DS Sync mais uniquement pour la lecture, il n'utilise pas le protocole RPC pour réinitialiser le mot de passe. Au lieu de cela, il exécute une requête LDAP pour localiser l'utilisateur correspondant dans Active Directory et tente de mettre à jour le mot de passe avec la demande en utilisant l'opération « IADsUser.ChangePassword ».
À ce stade, un contrôle de sécurité crucial est effectué : lorsque la requête LDAP est reçue par le contrôleur de domaine (DC), le Active Directory Le système d'autorisations vérifie si l'utilisateur qui tente de modifier le mot de passe dispose des autorisations nécessaires pour réinitialiser le mot de passe de l'utilisateur cible. Cela se fait en examinant l'ACL de l'utilisateur cible. Si l'utilisateur MSOL ne dispose pas de l'autorisation « Réinitialiser le mot de passe » sur l'entité, une erreur est renvoyée à Entra ID, indiquant que la mise à jour du mot de passe a échoué en raison d'autorisations insuffisantes. Si l'autorisation « Réinitialiser le mot de passe » est présente, la modification du mot de passe est effectuée avec succès.
La faille de sécurité
Au cours du processus de synchronisation, j'ai remarqué qu'il n'y avait pas de couverture complète des utilisateurs appartenant à des groupes privilégiés ou disposant d'autorisations plus élevées. Par conséquent, dans l'environnement Entra, ces utilisateurs ne reçoivent pas automatiquement le même statut privilégié que sur site. Par défaut, les utilisateurs hybrides ne bénéficient pas de la même protection que les rôles privilégiés dans Entra lors de la synchronisation initiale, sauf si l'administrateur réseau attribue manuellement ces privilèges et protections dans Entra ID.
En comprenant les capacités de synchronisation entre les deux environnements et la possibilité de resynchroniser les informations d'identification d'Entra vers les locaux, la question se pose : quels sont les risques potentiels impliqués ?
Le principal risque est d'obtenir des autorisations élevées dans AD sur site via un rôle d'administrateur faible dans Entra. Dans AD, un utilisateur peut recevoir des autorisations privilégiées mais ne pas nécessairement appartenir à un groupe protégé, ce qui l'expose aux attaques. Le même risque existe dans ce flux d'attaque ici :
Une fois qu'un attaquant prend le contrôle d'un Entra ID Un utilisateur disposant du rôle Administrateur de mots de passe peut exploiter son autorisation de réinitialisation de mot de passe pour élever ses autorisations, même s'il n'a pas d'utilisateur sur site. En réinitialisant le mot de passe d'un utilisateur disposant d'autorisations AD élevées, comme un utilisateur du groupe Administrateurs DNS, il peut prendre le contrôle du compte et potentiellement augmenter les privilèges au sein du domaine sur site.
Tout ce que l'attaquant doit faire est de se connecter avec le bon compte utilisateur, qui dispose au moins du rôle d'administrateur de mots de passe pour Entra IDPeu importe s'ils utilisent l'interface à https://entra.microsoft.com or https://portal.azure.com. Une fois connecté, il sélectionne l'utilisateur sur site cible et réinitialise simplement son mot de passe. Cela permet à l'attaquant de se connecter à l'environnement sur site avec le compte dont il a modifié le mot de passe.
Il est important de noter que si l’utilisateur ciblé fait partie d’un groupe protégé dans l’environnement local, l’attaque échouera.
Cela est dû au fait que la gestion des autorisations pour les utilisateurs protégés sur site bloque les modifications apportées par un Entra ID Connectez le compte aux utilisateurs de ces groupes protégés. Dans un environnement sur site, les groupes protégés peuvent être identifiés en examinant les adminCount attribut du groupe. Si le adminCount L'attribut est défini sur « 1 », cela indique que le groupe est considéré comme protégé. Ces groupes protégés suivent un modèle d'autorisations fixe qui est appliqué périodiquement. Toutes les heures, un mécanisme de protection est activé Active Directory exécute un processus qui vérifie si les autorisations du groupe dans le ACL correspondent aux autorisations définies dans le modèle. En cas de divergence, le processus réinitialise les autorisations pour les aligner sur le modèle.
Ce processus est géré par un mécanisme appelé SDProp (Security Descriptor Propagator), et le modèle d'autorisations est connu sous le nom AdminSDHolder.
Scénarios d'attaque exploitant cette faiblesse
Administrateurs fantômes
Administrateurs fantômes sont des utilisateurs qui peuvent réinitialiser le mot de passe d'un administrateur mais n'appartiennent à aucun groupe d'administrateurs. Étant donné que les deux sur site Active Directory et Entra ID Considérez ces administrateurs fantômes comme des utilisateurs normaux (sans protection spéciale par des groupes d'utilisateurs privilégiés), un attaquant peut exploiter leur capacité à réinitialiser le mot de passe d'un utilisateur privilégié dans Entra. Cela signifie que l'attaquant peut également réinitialiser le mot de passe de cet utilisateur dans l'environnement sur site.
Ce scénario offre aux attaquants une voie claire pour élever leurs privilèges et étendre leur contrôle sur le réseau, en profitant des autorisations élevées de l'utilisateur compromis.
Groupe d'administrateurs DNS
Un autre exemple est le groupe d'administrateurs DNS. Les administrateurs DNS gèrent les composants critiques de l'infrastructure réseau, en particulier les serveurs DNS. Étant donné que le groupe d'administrateurs DNS est configuré comme un groupe privilégié sans protection supplémentaire sur site, un attaquant pourrait facilement réinitialiser le mot de passe d'un membre du groupe d'administrateurs DNS via Entra. Cela lui donnerait un contrôle total sur ce compte dans l'environnement sur site.
Avec le contrôle d'un compte d'administrateur DNS, l'attaquant pourrait perturber considérablement les opérations du réseau. Il pourrait modifier les enregistrements DNS pour rediriger le trafic réseau interne, effectuer des L'homme du milieu (MITM) attaques en redirigeant le trafic via les serveurs qu'ils contrôlent ou en modifiant les paramètres DNS pour envoyer les utilisateurs vers des sites Web malveillants.
Propriétaires des créateurs de stratégie de groupe
Le groupe Propriétaires créateurs de stratégie de groupe est un autre exemple de groupe qui pourrait être un groupe privilégié sans protection supplémentaire. Les membres de ce groupe peuvent modifier les objets de stratégie de groupe (GPO) qu'ils ont créés. Si un attaquant accède à un compte de ce groupe, il peut exploiter ses autorisations pour modifier les GPO appliqués existants qui peuvent inclure des scripts ou des paramètres nuisibles, tels que des scripts susceptibles de voler des informations d'identification ou d'installer des programmes malveillants.
Groupe d'éditeurs de certificats
Éditeurs de certificats Le groupe est un autre exemple de groupe privilégié qui ne reçoit pas toujours l'attention nécessaire en matière de sécurité. Les membres de ce groupe ont la possibilité de publier des certificats Active Directory, qui joue un rôle clé dans l'organisation Infrastructure à clé publique (ICP). Si un attaquant accède à un compte qui fait partie du Éditeurs de certificats groupe, ils peuvent émettre ou manipuler des certificats, ce qui entraîne de graves risques de sécurité.
Par exemple, l’attaquant pourrait publier un certificat malveillant ou non autorisé pour usurper l'identité d'utilisateurs ou de services de confiance, leur permettant de mener des attaques MITM, de décrypter des communications sécurisées ou de contourner protocoles d'authentification contrôles. L'attaquant pourrait également augmenter les privilèges en émettant des certificats pour des comptes hautement privilégiés comme les administrateurs de domaine, ce qui entraînerait une compromission totale du domaine.
Atténuation des attaques
1. Lorsque vous utilisez une configuration d'identité hybride, comparez toujours les autorisations entre votre environnement sur site et Entra. De plus, assurez-vous que les utilisateurs privilégiés qui existent uniquement dans Entra et qui n'ont pas de comptes correspondants sur site ne reçoivent pas d'autorisations de réinitialisation de mot de passe. Cela permet d'empêcher tout accès externe non autorisé et tout contrôle sur votre environnement.
2. Lors de la configuration de la synchronisation entre les locaux Active Directory (AD) et Entra ID, il est essentiel de toujours vérifier les autorisations attribuées aux groupes privilégiés dans votre environnement sur site. Plus précisément, vous devez vous assurer que ces groupes ne disposent pas d'autorisations de modification de mot de passe inutiles.
Si vous remarquez que les membres de groupes privilégiés peuvent modifier leurs mots de passe, vous disposez de deux options pour résoudre ce problème :
- Supprimer manuellement les autorisations : vous pouvez ajuster manuellement les autorisations pour chaque groupe privilégié afin de supprimer la possibilité de modifier les mots de passe.
- Tirez parti du modèle AdminSDHolder : vous pouvez également modifier le adminCount attribut des groupes privilégiés d’être égal à « 1 », les protégeant ainsi.
L'AdminSDHolder est un modèle de sécurité dans Active Directory qui définit et applique les autorisations de sécurité pour les membres des groupes protégés. En ajoutant les groupes privilégiés à ce modèle, vous pouvez supprimer automatiquement leurs autorisations de modification de mot de passe.
