Auteur/autrice : psiracusa

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 !

L’UAC (User Account Control), 3 lettres pour désigner le système de contrôle d’accès introduit par Microsoft depuis Windows Vista.

Le but est d’alerter l’utilisateur lorsqu’une action nécessite des changements sur le système avec des privilèges plus élevés.

Exemple, un utilisateur administrateur de son poste souhaite lancer une invite de commandes en tant qu’administrateur :

Bien qu’étant administrateur de son poste, l’UAC se déclenche :

L’UAC embête certains utilisateurs (mais c’est pour leur bien !), les pentesters mais gêne surtout les auteurs de malwares car s’ils échouent à bypasser l’UAC, ils se dévoilent tout simplement.

C’est pourquoi beaucoup de techniques ont vu le jour pour bypasser l’UAC.

Une grande partie de ces techniques sont recensées sur ce GitHub :

https://github.com/hfiref0x/UACME

On s’aperçoit que pas mal de failles ont été corrigées par Microsoft mais d’autres toujours pas…

En fait pour Microsoft ce n’est pas vraiment un problème de sécurité car il ne s’agit pas d’une élévation de privilèges mais d’un bypass d’un avertissement de sécurité.

Chacun a son avis sur le sujet mais pour ma part je pense qu’il s’agit de vulnérabilités sérieuses et Microsoft devrait les corriger car elles sont largement utilisées par les malwares.

La société Lexfo en a parlé d’ailleurs récemment dans un post lié au ransomware « Lockbit » (très intéressant au passage) :

https://blog.lexfo.fr/lockbit-malware.html

A mon tour d’ajouter une petite pierre à l’édifice, j’ai en effet trouvé un petit bypass simple de l’UAC 🙂

Avant d’entrer dans le vif du sujet, un peu d’historique.

Les alertes de l’UAC étaient si fréquentes dans Vista que depuis Windows 7 et après de nombreuses plaintes, Microsoft a fait quelques concessions.

En effet certains binaires signés par Microsoft (ainsi qu’une liste d’objets COM) ne déclenchent pas d’alerte de l’UAC, on peut considérer cela comme une sorte de whitelist.

Quels sont ces binaires ?

Il suffit de rechercher les exécutables qui ont l’attribut « autoElevate » à « true » dans leur fichier manifest.xml :

sigcheck.exe -m c:\windows\system32\*.exe

Ces binaires sont intéressant car la moindre vulnérabilité permet d’ouvrir une brèche sur l’UAC.

Alors, let’s go !

Prérequis :

• UAC par défaut

• Utilisateur membre du groupe « Administrateurs » local.

On lance la commande lpksetup depuis une invite de commandes utilisateur.

L’exécutable « autoelève » ses privilèges mais pour les raisons citées précédemment l’UAC ne se déclenche pas :

On confirme avec Process Hacker que ce process dispose bien des privilèges élevés (Elevated = Yes et on a bien toute une liste de privilèges) :

S’agissant d’une application graphique, je me suis dit qu’il y a peut-être moyen de lancer un shell depuis l’interface et si c’est le cas cela bypasserait automatiquement l’UAC.

Et c’est le cas, après avoir lancé lpksetup allez dans « Installer ou désintaller des langues », cliquez sur « Parcourir » , sélectionnez un dossier où vous avez des droits en écriture, puis faites bouton droit, Propriétés.

Dans l’onglet « Personnaliser », cliquez sur « Choisir un fichier »

Dans la boite de dialogue saisir « cmd.exe » à la place du chemin du dossier et cliquez sur « Entrer » :

Et voila on obtient une invite de commandes Administrateur sans avoir rencontré l’UAC !

Le bypass manuel c’est bien mais le bypass automatique c’est mieux.

En analysant l’exécution de lpksetup.exe au travers de ProcMon, on s’aperçoit qu’il est vulnérable à du « DLL Hijacking » (« NAME NOT FOUND »)

Il suffit de créer une DLL contenant un « ShellExecute cmd.exe » qu’on nomme oci.dll et le tout est joué :

Pour ce coup là je ne suis pas le premier à avoir vu ce DLL Hijacking, mais Microsoft n’a toujours pas corrigé.