Comme c'est souvent le cas avec Active Directory, certaines des pires failles de sécurité sont dues à des configurations erronées qui laissent des portes ouvertes aux cybermenaces potentielles. Un paramètre courant que les cybercriminels adorent exploiter est la délégation sans contrainte.
Qu'est-ce que la délégation sans contrainte et pourquoi la délégation sans contrainte présente-t-elle un risque pour la sécurité ? La délégation consiste à autoriser un ordinateur à enregistrer les tickets d'authentification Kerberos d'un utilisateur, puis à utiliser ces tickets pour usurper l'identité de l'utilisateur et agir en son nom. La délégation sans contrainte est un paramètre de configuration nécessaire au fonctionnement de nombreuses applications web à plusieurs niveaux. Mais ce paramètre a des implications en termes de sécurité, car un ordinateur qui stocke les informations des tickets Kerberos pour un grand nombre d'utilisateurs serait une cible évidente pour les attaquants. Si ces derniers parviennent à s'emparer de ces tickets, ils peuvent agir avec l'identité et les privilèges de ces utilisateurs.
Si ce paramètre est si risqué, pourquoi les administrateurs configurent-ils les serveurs avec la délégation sans contrainte au lieu de la délégation avec contrainte traditionnelle ? Probablement parce que dans les premières versions de l'environnement Active Directory, c'était la seule forme de délégation prise en charge, et c'est aussi la plus facile à configurer, puisqu'elle ne nécessite qu'une seule case à cocher. Et si la configuration de la délégation sans contrainte permet à l'application de fonctionner, tout va bien, n'est-ce pas ? Mais il existe en fait une excellente raison de revoir ce paramètre. La suppression de la délégation sans contrainte élimine un maillon faible dans une chaîne d'authentification de confiance qui pourrait causer des dommages importants en cas d'abus.
Lecture associée
Les racines de la délégation sans contrainte
Les origines de ce risque potentiel pour la sécurité remontent à 20 ans. Microsoft a introduit la délégation sans contrainte de Kerberos dans Windows Server 2000 pour permettre aux services d'accéder à d'autres services au nom d'un utilisateur authentifié afin qu'il n'ait pas à se réauthentifier. Par exemple, si un utilisateur s'est authentifié auprès d'un serveur web, ce dernier peut alors usurper l'identité de l'utilisateur et accéder à des bases de données sans que l'utilisateur n'ait à saisir à nouveau ses informations d'identification. Lorsque la délégation sans contrainte est activée sur un compte, celui-ci peut se faire passer pour l'utilisateur auprès de n'importe quel service du même domaine.
Si cette fonctionnalité a facilité la vie des utilisateurs (et des administrateurs), elle a également présenté un risque évident. Si un serveur sur lequel la délégation sans contrainte est activée se trouve sous le contrôle d'acteurs menaçants, ceux-ci peuvent abuser de cette confiance pour obtenir un accès généralisé à l'ensemble de l'environnement. Microsoft a cherché à atténuer ce risque en introduisant la délégation restreinte dans Windows Server 2003, qui permet aux administrateurs de domaine de limiter les services auxquels un serveur donné peut accéder.
Avec la sortie de Windows Server 2012, Microsoft a donné aux administrateurs de services le pouvoir de décider si les services frontaux pouvaient accéder aux ressources dorsales. Avant ce changement, seul un administrateur de domaine pouvait contrôler les privilèges de délégation, ce qui ne permettait pas aux administrateurs de services de savoir quels services frontaux pouvaient accéder à la ressource qu'ils possédaient et, par conséquent, quelles étaient les voies d'attaque potentielles. Connue sous le nom de délégation restreinte basée sur les ressources (RBCD), cette approche de la délégation Active Directory est la plus difficile à utiliser de manière abusive.
En comparaison, la délégation sans restriction est la moins sécurisée. Si des attaquants parviennent à exploiter une délégation Kerberos non sécurisée, ils peuvent dissimuler toutes sortes d’activités malveillantes en se faisant passer pour un utilisateur légitime. Un acteur malveillant ayant accès à un serveur web présentant cette configuration pourrait voler le « Ticket Granting Ticket » (TGT) de l’utilisateur, stocké dans la mémoire du serveur, et l’utiliser pour usurper l’identité de cet utilisateur, exploiter ses privilèges d’accès ou étendre ses droits d’accès par une élévation de privilèges. Cette réalité fait de la délégation sans restriction un mécanisme idéal pour se déplacer latéralement dans l’environnement. Un TGT appartenant à un administrateur de domaine, par exemple, pourrait donner à l’attaquant l’accès à n’importe quel service de son choix — ou lui permettre potentiellement d’accéder à un compte KRBTGT et de lancer une attaque de type « Golden Ticket ».
Un pirate peut utiliser la cmdlet Get-ADComputer du module PowerShell d'Active Directory pour identifier les ordinateurs sur lesquels ce paramètre est activé, puis passer à l'action. Il peut par exemple utiliser Mimikatz pour extraire tous les tickets de service présents dans la mémoire du système. Les conséquences négatives d'une telle situation sont évidentes.
Améliorer la sécurité d'AD en désactivant la délégation sans contrainte
La bonne nouvelle, c'est que vous pouvez combler la faille de sécurité créée par la délégation sans restriction en désactivant simplement ce paramètre. Pour que la délégation sans restriction prenne effet, les administrateurs de domaine doivent l'activer pour les comptes en cochant la case « Faire confiance à cet ordinateur pour la délégation vers n'importe quel service (Kerberos uniquement) » dans l'onglet « Délégation » de la console de gestion ADUC.
Compte tenu des enjeux importants liés à l'activation de ce paramètre, les organisations peuvent renforcer leur sécurité en identifiant tous les serveurs sur lesquels la délégation sans restriction est activée, en désactivant ce paramètre et en le remplaçant par une délégation restreinte pour les serveurs qui en ont besoin. Les comptes administrateurs doivent être configurés avec l'option « Ce compte est sensible et ne peut pas faire l'objet d'une délégation », et les comptes disposant de privilèges élevés doivent être placés dans le groupe de sécurité « Utilisateurs protégés ». Les administrateurs peuvent rechercher les forêts comportant des relations de confiance entrantes qui autorisent la délégation TGT, ainsi que tout entité de sécurité autorisant la délégation sans restriction, à l’aide des scripts PowerShell. Vous pouvez également détecter la délégation sans restriction en examinant les événements Windows. Lorsqu’un ticket Kerberos est émis, un contrôleur de domaine Active Directory consigne des événements de sécurité contenant des informations sur le domaine cible. Vous pouvez examiner ces événements pour déterminer si la délégation sans restriction est utilisée dans le cadre des relations de confiance entrantes. Vous pouvez également télécharger et exécuter Purple Knight, un outil d’évaluation de la sécurité gratuit développé par les experts AD de Semperis qui analyse votre environnement AD à la recherche de plus de 80 indicateurs de sécurité, y compris la délégation sans restriction.
La désactivation de la délégation sans contrainte peut entraîner des problèmes de compatibilité pour certaines applications qui s'appuient sur cette fonctionnalité, ce qui signifie que vous devrez reconfigurer ces applications pour utiliser la délégation avec contrainte ou le RBCD. Comme toujours, les entreprises doivent garder à l'esprit que la sécurité AD ne se limite pas à la correction des vulnérabilités du code. Prévenir les attaques signifie également prendre des mesures pour réduire la surface d'attaque et prévenir de manière proactive les problèmes avant qu'ils ne surviennent.
