
Contourner UAC en détournant une DLL située dans le Native Image Cache
Contournez le Contrôle de compte d'utilisateur (UAC) pour obtenir des privilèges élevés (Administrateur) et exécuter n'importe quel programme à un niveau d'intégrité élevé.

J'ai décidé de mettre à jour ByeIntegrity pour le rendre plus rapide, léger et fiable. Il s'agit d'une refonte importante, j'ai donc créé un nouveau projet dans la solution VS appelé « ByeIntegrity2021 », qui est la version mise à jour de cette attaque. Bien sûr, la version originale est toujours présente. Pour plus d'informations sur la nouvelle version, développez les détails ci-dessous.
La nouvelle version est désormais capable de détourner le NIC sans dépendre des images natives existantes installées dans le NIC. Elle le fait en créant ses propres descripteurs d'image native et charges utiles, puis en les déplaçant dans le NIC, éliminant ainsi le besoin de :
*.ni existantes produites par NGEN.exeLe CLR charge les images natives depuis le NIC en effectuant un parcours récursif des répertoires de chaque entrée, puis en lisant son fichier *.aux. Ce fichier contient des informations sur l'image native et ses dépendances. En fonction des informations du fichier AUX, le CLR charge l'image ou la rejette, puis passe au candidat suivant. Si aucun candidat viable n'est trouvé, il charge l'image standard et utilise le jit pour la compiler normalement. Aucune partie de l'image native réelle n'est lue (seule son existence est vérifiée), donc ByeIntegrity place simplement la DLL de charge utile avec le même nom que l'image native aurait eu.
La version mise à jour de ByeIntegrity est livrée avec un outil appelé AUXGen, qui prend le nom d'un assembly du GAC et génère son fichier AUX correspondant. Le fichier AUX est généré de manière à correspondre aux vérifications du CLR, et le CLR chargera « l'image native » décrite par le fichier AUX. Note : AUXGen ne gère pas les dépendances lors de la génération du fichier AUX. Il ne fait que ce qui est nécessaire pour que le CLR charge l'image. Je publierai les détails du format du fichier AUX plus tard.
ByeIntegrity utilise désormais ISecurityEditor, comme le fait UACMe, ce qui réduit le code nécessaire. Il exige également que vous ayez généré le fichier AUX pour l'assembly MMCEx et que vous l'ayez placé dans le même répertoire que ByeIntegrity. MMCEx est maintenant l'image ciblée en raison de son ordre de chargement et de son nom plus court.
ByeIntegrity détourne une DLL située dans le Cache d'images natives (NIC). Le NIC est utilisé par le .NET Framework pour stocker des assemblys .NET optimisés générés par des programmes comme Ngen, le générateur d'images natives du .NET Framework. Comme Ngen est généralement exécuté sous l'utilisateur actuel avec des privilèges d'administrateur via le Planificateur de tâches, le NIC accorde un accès en modification aux membres du groupe Administrateurs.
Le composant logiciel enfichable du Pare-feu Windows de la console de gestion Microsoft (MMC) utilise le .NET Framework et, lors de son initialisation, les modules du NIC sont chargés dans le processus MMC. L'exécutable MMC utilise AutoElevate, un mécanisme que Windows utilise pour élever automatiquement le jeton d'un processus sans invite UAC.
ByeIntegrity détourne une DLL spécifique située dans le NIC nommée Accessibility.ni.dll. Il écrit du shellcode dans une zone de remplissage de taille appropriée située dans la section .text de la DLL. Le point d'entrée de la DLL est ensuite mis à jour pour pointer vers le shellcode. Lors du chargement de la DLL, le point d'entrée (qui est en fait le shellcode) est exécuté. Le shellcode calcule l'adresse de kernel32!CreateProcessW, crée une nouvelle instance de cmd.exe s'exécutant en tant qu'administrateur, puis retourne simplement TRUE. Cela ne concerne que la raison DLL_PROCESS_ATTACH ; toutes les autres raisons retournent immédiatement TRUE.
Cette attaque est implémentée dans UACMe sous la méthode #63. Si vous voulez essayer cette attaque, utilisez d'abord UACMe. L'attaque est la même, cependant UACMe utilise une méthode différente pour modifier le NIC. ByeIntegrity utilise IFileOperation tandis que UACMe utilise ISecurityEditor. De plus, UACMe choisit le bon Accessibility.ni.dll pour votre système et effectue les tâches de maintenance système si nécessaire (pour générer les composants du NIC). ByeIntegrity choisit simplement la première entrée NIC qui existe (qui peut ou non être la bonne entrée utilisée par MMC) et n'exécute pas les tâches de maintenance système. ByeIntegrity contient significativement plus de code que UACMe, donc lire l'implémentation UACMe sera beaucoup plus facile à comprendre que de lire le code de ByeIntegrity. Enfin, ByeIntegrity lance un processus enfant pendant l'attaque alors que UACMe ne le fait pas.
tl;dr : UACMe est plus simple et plus efficace que ByeIntegrity, donc utilisez d'abord UACMe.
Si vous lisez ceci, vous savez probablement comment compiler la source. Notez simplement que cela n'a pas été testé ni conçu pour x86, et cela ne fonctionnera probablement pas de toute façon sur x86.
Tout comme UACMe, je ne téléchargerai jamais de binaires compilés sur ce dépôt. Il y a toujours des gens qui veulent que le monde brûle et s'effondre, et je ne vais pas leur offrir une voie facile pour exécuter ceci sur l'ordinateur de quelqu'un d'autre et causer des dommages intentionnels. Je ne veux pas non plus que des script-kiddies utilisent cette attaque sans comprendre ce qu'elle fait et les dégâts qu'elle peut causer.
Cette attaque fonctionne de Windows 7 (7600) jusqu'à la dernière version de Windows.