Contourner le contrôle de compte d'utilisateur (UAC) en imitant les répertoires approuvés

L'expert en sécurité de l'information David Wells a publié un moyen de contourner les contrôles de compte d'utilisateur UAC dans Windows 10

Bonjour à tous!

En recherchant de nouvelles solutions de contournement pour le contrôle de compte d'utilisateur (UAC), j'ai découvert une solution de contournement complètement nouvelle pour UAC au moment de la rédaction de cet article. Il convient de noter que Microsoft ne considère pas l'UAC comme une limite de sécurité, cependant, nous signalons toujours divers bogues chez Microsoft et je souhaite partager les détails de la vulnérabilité que j'ai trouvée ici. Cette méthode a été testée avec succès sur Windows 10 Build 17134. Avant de plonger dans les détails de ma recherche, je vais d'abord vous donner une petite explication sur le fonctionnement du service UAC.

Apprêt Uac

Lorsqu'un utilisateur membre du groupe Administrateurs souhaite exécuter une application nécessitant des privilèges élevés, l'UAC affiche une demande correspondante et un utilisateur membre du groupe Administrateurs doit confirmer l'action. Cependant, cette demande UAC ne se produit pas pour TOUS les fichiers exécutables administrativement sous Windows. . Il y a quelques exceptions qui élèveront «automatiquement» les privilèges d'un fichier exécutable sans provoquer de requête UAC, en contournant UAC (à votre grande surprise!). Ce groupe particulier d'exécutables de confiance sélectionnés subit des vérifications de sécurité supplémentaires par le système pour s'assurer que ces fichiers sont réellement fiables, donc les attaquants en information n'abusent généralement pas de cette fonctionnalité. Cette approche a été utilisée dans les méthodes de contournement UAC précédentes et sera la base de ma nouvelle méthode de contournement. Cependant, il y a quelques failles que nous devons prendre pour que notre attaque réussisse. Examinons les exigences qui doivent être remplies si nous voulons que notre exécutable soit «automatiquement élevé en privilèges». Pour ce faire, je vais montrer quelques images de la bibliothèque désassemblée appinfo.dll (le service AIS qui traite les demandes d'escalade de privilèges est l'un des principaux composants de l'UAC).

Exigence 1: fichier configuré pour élever automatiquement les privilèges

Lorsqu'une demande d'augmentation de privilèges pour un programme se produit, le service AIS (appinfo.dll) effectue un appel RPC avec le chemin exécutable cible passé en argument. Ce service mappera ensuite le contenu exécutable cible du fichier à lire. Dans le manifeste du fichier exécutable, une tentative est faite pour lire la valeur pour obtenir la clé "autoElevate" (si elle existe).

Figure 1 - Lecture du manifeste du fichier exécutable pour obtenir la valeur de clé "autoElevate".



Si la valeur est reçue et qu'elle est True, le fichier sera considéré comme un fichier exécutable à privilèges élevés «automatique» qui s'exécutera avec une élévation de privilèges et n'appellera pas la boîte de dialogue du service UAC (à condition qu'il ait satisfait aux exigences suivantes mentionnées ci-dessous).

Figure 2 - appel de "bsearch" pour vérifier le nom du fichier exécutable dans la liste des exécutables "auto elevating"



Certains de ces fichiers qui sont programmés en dur dans le système sont sur liste blanche:
'cttunesvr.exe', 'inetmgr.exe', 'migsetup.exe', 'mmc.exe', 'oobe.exe', 'pkgmgr.exe', 'provisionshare.exe', 'provisionstorage.exe', 'spinstall .exe ',' winsat.exe '

Exigence 2: correctement signée

Il est supposé que la deuxième condition pour augmenter automatiquement les privilèges après l'envoi d'une demande à l'UAC est d'effectuer un contrôle de signature en utilisant «wintrust! WTGetSignatureInfo ".

Cela signifie que l'attaquant ne pourra pas simplement créer son propre fichier manifeste ou exécutable nécessaire à l'élévation "automatique" des privilèges et réussir, car le fichier binaire de l'attaquant sera très probablement incorrectement signé et la dernière condition, l'exécution, ne sera pas non plus remplie. à partir d'un répertoire de confiance.

Exigence 3: exécution à partir d'un répertoire de confiance

La dernière exigence pour obtenir une élévation de privilèges «automatique» est que l'exécutable cible se trouve dans un «répertoire de confiance», par exemple, «C: \ Windows \ System32». La figure 3 montre qu'AIS effectue cette vérification du chemin d'accès avec la demande de mise à niveau, auquel cas l'un des chemins considérés comme «de confiance» est «C: \ Windows \ System32».

Figure 3



Le titre de cet article est «Contourner le contrôle de compte d'utilisateur (UAC) en imitant les répertoires de confiance», de sorte que vous pouvez probablement facilement deviner ce qui va se passer ensuite.

Contournement UAC

Comme mentionné précédemment dans la section UAC Primer, le privilège automatique (contournement UAC) sera effectué pour les fichiers exécutables qui:

1. Configuré pour recevoir une élévation de privilèges «automatique»
2. Correctement signé
3. Exécuter à partir d'un répertoire approuvé ("C: \ Windows \ System32")

Appinfo.dll (AIS) utilise l'API RtlPrefixUnicodeString pour vérifier si le chemin du fichier exécutable correspond à «C: \ Windows \ System32 \» pour vérifier l'un des répertoires approuvés. Il s'agit d'un test de béton assez renforcé, compte tenu de sa comparaison avec l'emplacement du fichier canonique.

Par conséquent, afin de contourner cette vérification, je crée un répertoire appelé "C: \ Windows \" (notez l'espace après "Windows"). Bien sûr, en utilisant cette action, vous ne pouvez toujours pas passer la vérification RtlPrefixUnicodeString, et je mentionnerai également qu'il s'agit d'un nom de répertoire quelque peu invalide (ou au moins "hostile"), car Windows n'autorise pas l'ajout d'espaces à la fin du nom lors de la création du répertoire (essayez )

Cependant, en utilisant l'API CreateDirectory et en ajoutant "\\? \ "Au nom du répertoire que je veux créer, nous pouvons contourner certaines de ces règles de filtrage des noms et envoyer une demande de création du répertoire directement au système de fichiers.



Cela conduit à la création d'un répertoire gênant qui coexiste avec bonheur dans le système de fichiers avec le vrai "C: \ Windows \" (sauf lorsque vous essayez de faire quelque chose avec lui dans l'Explorateur Windows).



Maintenant que nous avons le répertoire «C: \ Windows \», nous pouvons y créer le répertoire «System32» et copier l'un des fichiers exécutables signés (qui est autorisé par le système à élever «automatiquement» les privilèges) du vrai répertoire «C: \ Windows \ System32 ".
Pour ce faire, j'ai copié «winSAT.exe» (l'un des fichiers de la liste blanche des fichiers exécutables Windows avec l'élévation «automatique» des privilèges autorisés par le système).
Lorsque nous essayons d'exécuter ce fichier à partir de notre nouveau répertoire «C: \ Windows \ System32 \ winSAT.exe», il passera par les API suivantes (voir figure 6) dans appinfo.dll avant d'effectuer une vérification de répertoire de confiance. Ceci est important et explique pourquoi cette solution de contournement fonctionne.

Figure 6



Lorsque ce chemin gênant avec un espace est envoyé à AIS pour demander une élévation de privilèges, le chemin est transmis à GetLongPathNameW, qui le reconvertit en «C: \ Windows \ System32 \ winSAT.exe» (espace supprimé).

Super!

Maintenant, c'est la ligne où la vérification de répertoire valide est passée (à l'aide de RtlPrefixUnicodeString) pour le reste de la vérification.

La beauté de ma solution est qu'après avoir vérifié le répertoire de confiance, ce chemin converti est exécuté, qui est ensuite libéré, et les vérifications restantes (et la dernière demande d'escalade de privilèges) sont effectuées avec le nom d'origine du répertoire exécutable (avec un espace supplémentaire).

Cela vous permet de passer par toutes les autres vérifications et amène appinfo.dll à accepter ma copie de winSAT.exe comme avec une élévation "automatique" des privilèges (car elle est correctement signée et ajoutée à la liste blanche pour l'élévation "automatique" des privilèges).

Pour utiliser réellement le code malveillant, je viens de copier le faux WINMM.dll (importé winSAT.exe) dans mon répertoire actuel "C: \ Windows \ System32 \" pour usurper la DLL locale. Le concept complet peut être vu dans la figure ci-dessous.

Figure 7



→ Lien vers Github