Je vous propose aujourd'hui un article que j'avais commencé il y a un petit moment.
Nous allons voir une technique pour mettre en place une "backdoor" permettant d'accéder aux mots de passe gérés par LAPS sans avoir à modifier les ACLs sur les objets ordinateurs.
Cette technique peut permettre à un attaquant de refaire rapidement une élévation de privilèges.
Concept
Le concept de cette technique est relativement simple.
La protection du mot de passe géré par LAPS est assuré par la confidentialité de l'attribut ms-mcs-admpwd. Toute la solution repose sur ce flag de confidentialité. En désactivant la confidentialité de l'attribut, tout le monde peut lire le mot de passe contenu dans l'attribut.
L'intérêt de cette technique est qu'elle ne nécessite pas de modification des ACL sur les objets et qu'elle n'impacte pas le fonctionnement de la solution.
La probabilité qu'un administrateur se rende compte de cette modification est relativement faible.
Utilisation de DCShadow
Dans la vidéo DCShadow modying the schema without being noticed Vincent montre comment faire des modifications dans le schéma sans modifier l'attribut schemaInfo.
Pour le coup je ne suis pas complètement d'accord avec lui puisque dans son exemple il ne modifie pas les métadonnées de réplication. On peut donc facilement retrouver la modification effectuée dans la vidéo via les métadonnées.
Je note d'ailleurs que le code mis à jour n'utilise plus 42 comme valeur d'USN par défaut mais se base sur la plus haute valeur d'USN émise par le DC. Cette modification permet donc de répliquer les modifications effectuées via DCShadow lorsque l'on ne spécifie pas de numéro USN.
Afin de rester le plus discret possible, je vais altérer les métadonnées.
Il faut donc d'abord récupérer les métadonnées. C'est faisable rapidement avec powershell et le module AD.
On a donc toutes les informations qui nous intéressent.
On peut donc préparer notre commande DCShadow.
Il nous faut juste la valeur à mettre dans l'attribut (voir Search Flags ).
Dans notre cas, il faut enlever le flag de confidentialité. La nouvelle valeur sera donc : 776 (0x308 au lieu de 0x388).
Pour être encore plus discret, je vais cibler un DC qui sera moins suceptible d'être utiliser par les administrateurs (un DC d'un site distant par exemple). Un rapide coup d'oeil au code source d'AdmPwd ne montre pas de ciblage d'un DC en particulier par les Cmdlets du module.
Je vérifie déjà que mon utilisateur n'a pas accès au mot de passe (j'utilise les Cmdlets du module ActiveDirectory pour cibler le DC).
Je prépare ma commande DCShadow (Je cible un DC en particulier + altération des métadonnées).
Je pousse la modification en ciblant le DC.
On peut vérifier que la modification est effective et qu'une partie des métadonnées n'ont pas changées (LastOriginatingXXX).
On remarque qu'il y a 2 attributs qui ont changé: la version et la valeur de l'USN local.
Si on vérifie avec l'autre DC, les modifications n'ont pas été répliquées (ce qui est voulu dans notre cas). mais les métadonnées sont identiques (sauf la version).
Il ne reste plus qu'à vérifier le bon fonctionnement.
On récupère bien désormais le mot de passe en ciblant le DC.
On a donc un DC qui nous permet de récupérer les mots de passe avec n'importe quel compte (user et computer) et on n'a pas altéré le fonctionnement de la solution. En ciblant un DC moins susceptible d'être utilisé par les admins il y a moins de risque que la modification soit découverte.
Cet exemple est facilement déclinable à d'autres backdoors déjà connues (DCSync que sur un DC par exemple...).
Plus l'infra de la cible comporte de DC et plus il sera difficile de détecter ce genre de backdoor.
Contre-mesures et détection
Pour la partie LAPS, il est possible de mettre en place un audit de l'accès à l'attribut ms-mcs-admpwd pour savoir qui accède en lecture à l'attribut.
Je ne l'ai pas testé mais il n'y a pas de raison que ce ne soit pas fonctionnelle.
Pour DCShadow ça devient difficile. On a vu que le numéro de version était différent, le LocalChangeUSN aussi.
On peut détecter l'utilisation de cette technique en comparant les métadonnées de l'attribut searchFlags avec celles de l'attribut CN qui n'est pas répliqué mais est créé sur le DC au moment de la création de l'objet.
En comparant la valeur de LocalChangeUSN et la date entre les 2 attributs on peut voir l'incohérence du LocalChangeUSN de l'attribut searchFlags par rapport à celui du CN.
Mais bon, voilà quoi ...
Autant dire quasi impossible en vrai.
Aucun commentaire:
Enregistrer un commentaire