l3cr0f/dccwbypassuacContournement d'UAC sur Windows 8.1 et 10 en abusant de WinSxS dans « dccw.exe ».
Cet exploit exploite la façon dont « WinSxS » est géré par « dccw.exe » au moyen d'une méthode dérivée du « Bypass UAC » de Leo Davidson afin d'obtenir un shell administrateur sans invite de consentement. Il prend en charge les architectures « x86 » et « x64 ». De plus, il a été testé avec succès sur Windows 8.1 9600, Windows 10 14393, Windows 10 15031 et Windows 10 15062.
Si vous voulez savoir comment exécuter le script, consultez la section utilisation. Vous pouvez également l'exécuter dans Metasploit et obtenir une session Meterpreter avec les droits administrateur.
Pour développer un nouveau contournement de l'UAC, il faut d'abord trouver une vulnérabilité dans le système et, plus précisément, une vulnérabilité dans un processus à élévation automatique. Pour obtenir une liste de ces processus, nous avons utilisé l'outil Strings de Sysinternals. Après cela, nous avons pu constater que certains processus à élévation automatique comme « sysprep.exe », « cliconfig.exe », « inetmgr.exe », « consent.exe » ou « CompMgmtLauncher.exe » présentaient (certains présentent encore) des vulnérabilités permettant l'exécution d'un « bypass UAC ». Nous avons donc commencé à étudier le fonctionnement d'autres processus à élévation automatique avec l'application Process Monitor (ProcMon) de Sysinternals, mais en nous concentrant sur le processus « dccw.exe ».
Cependant, avant de commencer à utiliser ProcMon, nous avons d'abord vérifié le manifeste de ces applications avec une autre application de Sysinternals appelée Sigcheck et, bien entendu, dans notre cas, « dccw.exe » est un processus à élévation automatique.
Ensuite, nous avons pu commencer à suivre le flux d'exécution de « dccw.exe » avec ProcMon pour voir si quelque chose d'étrange se produisait, ce que nous avons vérifié immédiatement. À un moment donné, si « dccw.exe » est exécuté en tant que processus 64 bits sur une machine Windows 64 bits, il recherche le répertoire « C:\Windows\System32\dccw.exe.Local\ » pour charger une DLL spécifique appelée « GdiPlus.dll », comme s'il était exécuté sur une machine Windows 32 bits. En revanche, s'il est exécuté en tant que processus 32 bits sur la même machine, le processus recherchera le répertoire « C:\Windows\SysWOW64\dccw.exe.Local\ ». Ensuite, étant donné que celui-ci n'existe pas, le processus cherche toujours un dossier dans le chemin « C:\Windows\WinSxS\ » pour obtenir la DLL souhaitée. Ce dossier porte un nom dont la structure est la suivante :
[architecture]_microsoft.windows.gdiplus_[code_séquentiel]_[version_de_windows]_none_[numéro_séquentiel]
Si nous examinons le répertoire « WinSxS », nous pouvons voir plus d'un dossier correspondant à cette structure, ce qui signifie que « dccw.exe » peut charger la DLL souhaitée à partir de n'importe lequel de ces dossiers. La seule chose dont nous sommes sûrs est que si l'application est invoquée en tant que processus x86, le nom du dossier commencera par la chaîne « x86 », tandis que si elle est exécutée en tant que processus x64, son nom commencera par la chaîne « amd64 ».
Cette situation peut être exploitée pour effectuer un détournement de DLL (DLL hijacking) puis exécuter du code avec une intégrité élevée, sans invite de consentement.
Une fois que nous avons trouvé une erreur lors de l'exécution d'un processus à élévation automatique, nous devons vérifier si elle peut être exploitée ou non. Pour ce faire, nous avons simplement créé le dossier « dccw.exe.Local » dans le chemin souhaité et, dans ce dossier, nous avons créé les dossiers situés dans « WinSxS » qui pouvaient être invoqués par le processus pour charger « GdiPlus.dll », mais sans cette DLL.
Maintenant, si nous exécutons « dccw.exe », nous verrons que le processus a trouvé le dossier « dccw.exe.Local » et l'un des dossiers « WinSxS », mais pas la DLL souhaitée, ce qui génère une erreur. C'est ce que nous attendions, car cette situation peut être exploitée par un attaquant comme nous l'avons mentionné précédemment.
À ce stade, nous savons déjà que nous pouvons contourner l'UAC sur Windows 10 en abusant de « dccw.exe », mais comment ?
La méthode la plus utilisée pour contourner l'UAC est celle développée par Leo Davidson. Cependant, elle effectue une injection de processus pour invoquer l'objet COM IFileOperation, ce qui peut être détecté par certains logiciels antivirus. Une meilleure approche consiste donc à utiliser celle appelée Masquerade PEB, utilisée par Cn33liz dans son propre contournement de l'UAC.
De plus, nous devons modifier la façon dont IFileOperation est invoqué dans les versions plus récentes de Windows 10, car la méthode de Leo Davidson déclenche l'UAC à partir de la build 15002. La manière d'invoquer cette opération est donc la même que l'originale, mais sans les indicateurs d'opération « FOF_SILENT », « FOFX_SHOWELEVATIONPROMPT » et « FOF_NOERRORUI ».
Avant d'exécuter l'exploit, il est important de vérifier certains aspects afin de ne pas l'exécuter sans succès et de déclencher ainsi des alarmes. La première chose que nous vérifions est la version de build de Windows, car certaines versions ne sont pas vulnérables à notre exploit (celles dont la version de build est inférieure à 7600). Ensuite, nous vérifions que nous ne disposons pas encore des droits administrateur ; si c'était le cas, il n'y aurait aucune raison d'exécuter le script. Puis, nous vérifions les paramètres de l'UAC afin de confirmer qu'ils ne sont pas définis sur « Toujours notifier » (« Always notify »), car si c'était le cas, notre exploit serait inutile. Enfin, nous vérifions si l'utilisateur appartient au groupe des administrateurs, car, dans le cas contraire, l'exploit échouerait.
Lorsqu'un exploit est développé, il est important qu'il puisse fonctionner sur le plus grand nombre de systèmes possible, y compris les systèmes Windows 32 bits. Pour y parvenir, nous devons compiler notre exploit pour ces systèmes, afin de pouvoir également l'exécuter sur des systèmes 64 bits.
Lorsque notre exploit 32 bits est exécuté sur une machine Windows 64 bits, la façon dont « dccw.exe » fonctionne est un peu différente en raison de l'invocation de WOW64 (le sous-système Windows qui permet aux machines 64 bits d'exécuter des applications 32 bits). Cela signifie que le dossier « dccw.exe.Local » sera recherché dans le répertoire « C:\Windows\SysWOW64\ » au lieu de « C:\Windows\System32\ », mais aussi que la « GdiPlus.dll » ciblée sera une DLL 32 bits, ce qui implique qu'elle sera recherchée dans un dossier correspondant au modèle de nom « C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_* ». Toutefois, s'il est exécuté sur un système Windows 32 bits, l'exploit fonctionnera comme prévu.
Enfin, il est important de souligner que nous devons prendre en compte tous les chemins correspondant au modèle « C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_* » lors du détournement de DLL afin de garantir une efficacité de 100 %.
Pour exécuter un processus avec une intégrité élevée, nous devons développer une DLL qui sera invoquée via un détournement de DLL. Cependant, ce n'est pas aussi simple qu'il y paraît, car si nous ne faisons que cela, ni « dccw.exe » ni notre code ne seront exécutés. Cela est dû au fait que « dccw.exe » dépend de certaines fonctions de « GdiPlus.dll ». Nous devons donc implémenter ou rediriger l'exécution de ces fonctions vers la DLL légitime.
La meilleure option consiste à rediriger l'exécution vers la DLL légitime, car de cette façon, la taille de notre DLL sera plus réduite. Pour ce faire, nous avons utilisé le programme ExportsToC++ pour porter toutes les exports de « GdiPlus.dll » vers le langage C++. Le problème réside maintenant dans le nombre considérable d'exports de « GdiPlus.dll », 631 pour être précis. Néanmoins, « dccw.exe » ne les importe pas toutes, mais seulement quelques-unes. Pour savoir quelles fonctions sont importées par « dccw.exe » depuis « GdiPlus.dll », nous avons fait de la rétro-ingénierie avec « IDA Pro ». Finalement, seulement 15 fonctions sont importées depuis « GdiPlus.dll », nous n'avons donc qu'à inclure celles-ci dans notre DLL.
Maintenant, le problème semble résolu, mais si nous redirigeons l'exécution vers une « GdiPlus.dll » spécifique dans « C:\Windows\WinSxS\ », la DLL ne fonctionnera que sur certains systèmes, car le nom des dossiers internes de « WinSxS » change à chaque build de Windows. Pour surmonter ce problème, nous avons eu l'idée de rediriger l'exécution vers « C:\Windows\System32\GdiPlus.dll », car ce chemin est le même sur tous les systèmes Windows 10
La dernière chose à faire est d'arrêter l'exécution de « dccw.exe » après l'exécution de notre code malveillant afin d'éviter l'ouverture de la fenêtre de ce processus.
Maintenant, une fois notre DLL malveillante développée, nous devons la déposer sur la machine ciblée. Pour ce faire, notre DLL a été compressée et encodée en « base64 » dans l'exploit, afin de pouvoir être décodée et décompressée à l'exécution pour être déposée comme prévu.
Enfin, notre « GdiPlus.dll » spécialement conçue est copiée vers l'emplacement ciblé à l'aide de l'objet COM IFileOperation, comme mentionné précédemment.
Lorsqu'un attaquant compromet un système, il veut rester non détecté le plus longtemps possible, ce qui signifie supprimer toute trace des actions qu'il effectue. Pour cette raison, tous les fichiers temporaires créés pendant l'exécution de l'exploit sont supprimés dès qu'ils ne sont plus nécessaires.
Enfin, nous devons déterminer quel processus nous voulons exécuter avec une intégrité élevée. Dans notre cas, nous avons choisi l'application « cmd.exe » car elle nous permet d'effectuer autant d'opérations avec une intégrité élevée que nous le souhaitons une fois que nous disposerons des droits administrateur, mais, en réalité, nous pouvons exécuter n'importe quelle application.
Pour exécuter l'exploit, vous devez vous assurer que la machine ciblée satisfait aux exigences. Ensuite, il vous suffit d'exécuter l'exploit comme n'importe quel autre script en ligne de commande :
C:\Users\L3cr0f> DccwBypassUAC.exe
Le module Metasploit de cette preuve de concept (PoC) utilise une injection de DLL au lieu de Masquerading PEB et il est disponible ici :
- Metasploit Framework : https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/windows/local/bypassuac_injection_winsxs.rbCet exploit a été développé pour montrer comment un attaquant pourrait obtenir des privilèges sur un système, et non pour être utilisé à des fins malveillantes. Cela signifie que je décline toute responsabilité si quelqu'un l'utilise pour commettre des activités criminelles.
Le contrôle de compte d'utilisateur (UAC) est une technologie introduite avec Windows Vista qui fournit une méthode de séparation entre les privilèges et les tâches d'un utilisateur standard et ceux qui nécessitent un accès administrateur. Si un utilisateur standard utilise le système et tente d'effectuer une action pour laquelle il n'a pas d'autorisation, une invite Windows apparaît et demande le mot de passe du compte Administrateur. Si un administrateur utilise le système et tente d'effectuer la même tâche, une simple invite d'avertissement apparaît. Cette invite est connue sous le nom d'« invite de consentement » (« Consent Prompt ») car l'administrateur est seulement invité à approuver l'action avant de continuer. Une faiblesse qui permettrait de contourner l'« invite de consentement » n'est pas considérée comme une vulnérabilité de sécurité, car cela n'est pas considéré comme une frontière de sécurité.
Cependant, Microsoft déclare également que « le contrôle de compte d'utilisateur (UAC) est un composant fondamental de la vision globale de Microsoft en matière de sécurité ».
Sources :
- Définition d'une vulnérabilité de sécurité.
- Fonctionnement du contrôle de compte d'utilisateur.