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é.