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 contrainte est la moins sûre. Si les attaquants peuvent abuser d'une délégation Kerberos non sécurisée, ils peuvent masquer toutes sortes d'activités malveillantes en imitant un utilisateur légitime. Un acteur menaçant ayant accès à un serveur web avec cette configuration pourrait voler le Ticket Granting Ticket (TGT) de l'utilisateur, qui est stocké dans la mémoire du serveur, et l'utiliser pour usurper l'identité de cet utilisateur et tirer parti de ses privilèges d'accès ou améliorer l'accès par l'escalade des privilèges. Cette réalité fait de la délégation sans contrainte un mécanisme idéal pour les mouvements latéraux dans l'environnement. Un TGT appartenant à un administrateur de domaine, par exemple, pourrait permettre à l'attaquant d'accéder à n'importe quel service de son choix - ou d'accéder potentiellement à un compte KRBTGT et de lancer une attaque de type Golden Ticket.
Un pirate peut utiliser la cmdlet Get-ADComputer du module Active Directory PowerShell pour trouver les ordinateurs sur lesquels ce paramètre est activé, puis se mettre au travail. Il peut utiliser Mimikatz, par exemple, pour extraire chaque ticket de service dans la mémoire du système. Les conséquences négatives de cette 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 contrainte en désactivant simplement ce paramètre. Pour que la délégation sans contrainte 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 à n'importe quel service (Kerberos uniquement)" dans l'onglet Délégation de la console de gestion ADUC.
Étant donné l'importance des enjeux liés à l'activation de ce paramètre, les entreprises peuvent améliorer leur sécurité en identifiant les serveurs sur lesquels la délégation sans contrainte est activée, en désactivant ce paramètre et en le remplaçant par une délégation avec contrainte pour les serveurs qui en ont besoin. Les comptes d'administration doivent être configurés sur "Le compte est sensible et ne peut pas être délégué", et les comptes à privilèges élevés doivent être placés dans le groupe de sécurité des utilisateurs protégés. Les administrateurs peuvent rechercher les forêts avec des trusts entrants qui autorisent la délégation TGT et tous les principes de sécurité qui autorisent la délégation sans contrainte à l'aide des scripts PowerShell. Vous pouvez également détecter la délégation sans contrainte en examinant les événements Windows. Lorsqu'un ticket Kerberos est émis, un contrôleur de domaine Active Directory enregistre des événements de sécurité contenant des informations sur le domaine cible. Vous pouvez examiner ces événements afin de déterminer si la délégation sans contrainte est utilisée dans le cadre d'accords de confiance entrants. Vous pouvez également télécharger et exécuter Purple Knightun outil gratuit d'évaluation de la sécurité conçu 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 contrainte.
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.
