Catégorie : PENTEST

Un mini-tuto sur l’outil PetitPotam, rien d’extraordinaire, juste un petit récap des différentes étapes.

Au cas où vous auriez vécu dans une grotte, PetitPotam est un outil permettant de relayer l’authentification NTLM d’un serveur Windows.

Cela tombe vraiment à pic depuis que tout le monde a désactiver le PrintSpooler sur les DC 🙂

Ce qui est génial c’est que vous n’avez même pas besoin de disposer au préalable d’un compte du domaine, pas mal non ?

Ce qu’on rencontre le plus souvent en ce moment c’est le relai NTLM d’un contrôleur de domaine vers le serveur web de certificat interne à l’entreprise dans le but de récupérer un certificat machine du DC.

Pour ce faire il suffit de récupérer une version de l’outil ntlmrelayx (avec support du relai vers un serveur AD Certificate Service en HTTP)

Un petit exemple sur mon lab où 192.168.112.135 est l’adresse IP de mon serveur de certificat :

Une fois le relai NTLM en écoute y a plus qu’à lancer PetitPotam en ciblant une machine intéressante, au hasard un contrôleur de domaine.

Ici dans mon lab 192.168.112.130 est l’adresse IP de mon serveur relai et 192.168.112.132 est l’adresse IP de mon DC.

De retour sur ma machine de relai NTLM, j’obtiens le certificat du DC :

On peut faire un tour sur le serveur d’autorité de certificat pour vérifier l’existence de ce certificat machine :

Une fois ce certificat machine en main, vous pouvez ensuite générer un ticket Kerberos TGT pour le DC avec par exemple l’outil Rubeus :

Rubeus.exe asktgt /user:<user> /certificate:<base64-certificate> /ptt

Une fois le ticket TGT en mémoire vous pouvez devenir maître du domaine avec l’attaque DCsync qui pour rappel permet de récupérer tous les hashs du domaine, rien que ça.

mimikatz.exe lsadump::dcsync /domain:kahlon.local /all /csv

Avec tous ces hashs vous pouvez choisir au hasard le hash d’un administrateur du domaine pour faire une attaque de type Pass-The-Hash

mimikatz.exe privilege::debug sekurlsa::pth /user:Administrator domain:kahlon.local /ntlm:xxxxxxxxxxxxxxxx

Et voila échec et mat

Pour tout un chacun, une application qui crash est un moment d’énervement, cela arrive sans prévenir et malheureusement souvent au pire moment.

Mais pour un pentester une application qui crash peut être l’opportunité d’une élévation de privilèges.

Il n’y a pas longtemps mon client Lotus Notes a crashé et comme j’avais l’explorateur de fichiers ouvert, j’ai noté la création d’un répertoire IBM_TECHNICAL_SUPPORT avec des fichiers de debug dedans.

Ce qui est intéressant c’est que ce répertoire est créé dans le profil utilisateur, parfaitement accessible en lecture et modification :

Pour savoir si ce crash en vaut la peine, il faut déterminer le nom du processus responsable de l’écriture de ce répertoire IBM_TECHNICAL_SUPPORT.

En faisant divers tests et en observant les processus au travers de Procmon, on s’aperçoit rapidement que c’est le service nsd.exe qui en est responsable :

Et devinez sous quel compte tourne ce service ?

Sous le compte Local System !

En résumé nous avons un service qui tourne sous Local System écrivant des fichiers dans un répertoire accessible par l’utilisateur en lecture/écriture.

Nous avons donc une vulnérabilité pouvant éventuellement mener à une élévation de privilège.

Vérifions que le détournement de répertoire fonctionne.

Il faut commencer par quitter le client Notes et supprimer le répertoire IBM_TECHNICAL_SUPPORT.

Ensuite nous pouvons créer un lien symbolique vers le répertoire système C:\Windows\system32 dans lequel en tant que simple utilisateur nous ne pouvons pas évidemment pas écrire :

mklink /J <USER ROAMING PROFILE>\Domino\IBM_TECHNICAL_SUPPORT "C:\Windows\System32"

Ensuite il suffit de lancer le client Notes et de le faire crasher comme ci-dessous :

Et comme attendu, des fichiers de debug ont été créés dans le répertoire système C:\Windows\System32 !

Ce type de vulnérabilité est assez courant et peut permettre une élévation de privilège à condition de pouvoir contrôler certains paramètres comme les noms des fichiers cibles et les permissions.

Je ne suis pas allé plus loin dans l’analyse et libre à vous de creuser l’affaire, notamment avec la technique d’indirection RPC Control (exemple : https://decoder.cloud/2020/10/27/when-a-stupid-oplock-leads-you-to-system/) et pourquoi pas dénicher une nouvelle CVE et au passage un peu de cash 🙂

Qui n’a jamais tenté en vain d’être administrateur local après avoir essayé de multiples techniques ?

Vous allez voir qu’il est possible d’écrire dans les répertoires système normalement réservés aux administrateurs en 1 click !

Mais comment ?

Lancez une invite de commandes en tant que simple utilisateur et allez ensuite dans le gestionnaire de tâches.

Repérez le processus associé à votre invite de commandes et activer la virtualisation du contrôle de compte utilisateur (par défaut cette option est désactivée).

Et voila c’est tout ? Oui ! Vous pouvez maintenant écrire dans C:Windows\System32 !

La preuve, avec la commande précédente, echo Pwned > haha.txt, le fichier haha.txt est bien présent dans C:\Windows\System32 :

Bon allons voir maintenant ce fichier au niveau de l’explorateur de fichiers :

Il n’y est pas, que se passe t-il ?

Le fichier haha.txt n’est pas présent dans l’explorateur de fichiers alors qu’on le voit bien dans l’invite de commandes, c’est bizarre ça !

Mais alors je vous aurez menti ?

En quelque sorte oui ! Avez-vous fait attention à la date de ce post ? Il est du 1er avril 2021, poisson d’avril 🙂

Néanmoins où est ce fichier s’il n’est pas dans C:\Windows\System32 ?

Et bien ce fichier se trouve dans un répertoire où vous avez le droit d’écrire (et oui ce n’est pas magique), dans AppData\Local\VirtualStore :

C’est quoi ce tour de passe-passe ?

Dans mon dernier post je parlais d’une technique de bypass de l’UAC et bien là il s’agit de la virtualisation de l’UAC.

Windows permet aux applications qui ne sont pas écrites pour UAC de s’exécuter dans les comptes d’utilisateur standard à l’aide de la virtualisation du système de fichiers et de l’espace de noms du registre.

Lorsqu’une application modifie un emplacement de système global dans le système de fichiers ou dans le registre, et que cette opération échoue parce que l’accès lui est refusé, Windows redirige l’opération vers une zone propre à l’utilisateur.

Cette virtualisation de l’UAC s’appuie sur un mini filter driver, nommé luafv. Vous pouvez afficher la liste de ces mini filters drivers avec la commande fltmc (il faut être admin local, vraiment cette fois, pour pouvoir lancer cette commande) :

Vous avez remarqué la colonne « Altitude », à quoi sert-elle ?

Plus la valeur d’altitude est élevée, plus la priorité est élevée. Par exemple,
un filtre à l’altitude 10000 sera appelé avant un filtre à l’altitude 5000.

Lors du traitement des réponses, les altitudes sont traitées dans l’ordre inverse,
de sorte que le filtre à 5000 sera appelé en premier, puis celui à 10000.

Officiellement, les valeurs d’altitude doivent être enregistrées auprès de Microsoft (https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/allocated-altitudes).

Voila, il y aurait pas mal d’autres choses à dire sur ces mini filter drivers, notamment comment les exploiter en tant que pentester pour de l’élévation de privilèges vers Local System.

Si ce sujet vous intéresse je ne peux que vous conseillez la lecture de ce post :

https://googleprojectzero.blogspot.com/2021/01/hunting-for-bugs-in-windows-mini-filter.html

Joyeuses Pâques !