Injection de DLL dans le service IKEEXT : un moyen (encore) efficace pour élever ses privilèges sous Windows – Partie 2/2

5. Correctif

Avant de considérer l’un des correctifs qui vont suivre, il est important de rappeler que Microsoft n’a pas reconnu cette faiblesse du service IKEEXT comme étant une vulnérabilité et n’a donc pas déployé de correctif. La firme de Redmond justifie ce point de vue par le fait que, par défaut, le système d’exploitation n’est pas vulnérable. C’est en effet l’installation d’un logiciel tiers avec un défaut de configuration des permissions sur ses dossiers qui rend cette faiblesse exploitable.

Toutefois, nous allons voir que le géant américain n’est pas resté si indifférent que cela face à cette faille potentiellement critique. Pour s’en rendre compte, revenons tout d’abord sur le processus de recherche de la DLL wlbsctrl.dll sous Windows 7 Professionnel. Comme illustré en introduction, la DLL en question est en effet recherchée dans les répertoires système puis dans les dossiers inscrits dans le « PATH ».

Refaisons maintenant cet exercice sous Windows 10 Professionnel et observons ce qu’il se passe :

Fig. 2 : Analyse du chargement des DLL du service IKEEXT sous Windows 10 Pro.


La différence est de taille ! Cette fois-ci, le système se contente de chercher dans le dossier C:\Windows\System32\ alors que le fichier n’y est toujours pas présent manifestement, le résultat étant toujours « NAME NOT FOUND ». Il semblerait donc qu’un correctif ait tout de même été appliqué sur les versions plus récentes du système d’exploitation.

La première solution que nous pourrions envisager serait alors d’effectuer une mise à niveau de l’ensemble du parc de machines vers Windows 10. Toutefois, un tel chantier peut poser de nombreux autres problèmes, voire présenter des risques qui ne sont pas encore maîtrisés à ce jour. On pensera notamment aux problèmes de confidentialité, mis en lumière par de nombreux chercheurs en sécurité, et appuyés au plus haut niveau par la CNIL avec l’annonce de la mise en demeure de Microsoft le 20 juillet dernier [6].

Une solution plus simple et efficace à court ou moyen terme consiste à vérifier les permissions de tous les dossiers inscrits dans la variable d’environnement PATH du système de chaque machine. Cette liste peut être facilement obtenue en accédant à la clé de registre suivante :

\HKEY_LOCAL_MACHINES\SYSTEM\CurrentControlSet\Control\Session Manager\Environnement.

La vérification pourra alors être automatisée grâce à un script PowerShell et les droits d’écriture seront retirés aux utilisateurs le cas échéant.

Bien qu’efficace, cette solution peut poser un autre problème dans certaines situations. Nous avons en effet rencontré plusieurs cas où le fait de retirer les droits d’écriture à l’utilisateur entraîne le dysfonctionnement de l’application concernée. Une solution plus radicale consiste alors à désactiver totalement le service IKEEXT, même si Microsoft recommande le contraire, car cela empêchera l’utilisation du protocole IPSec dans ce contexte. Dans le cas d’utilisateurs nomades, il serait alors nécessaire de vérifier l’éventuelle présence d’effets de bords avec les clients VPN utilisés.

En définitive, si vous utilisez toujours Windows 7 ou Windows Server 2008 R2, méfiez-vous des logiciels tiers qui seront installés. Ils risqueraient de faire tomber l’épée de Damoclès qui pèse toujours sur ces systèmes d’exploitation. Par ailleurs, à chaque fois que nous avons rencontré cette vulnérabilité, il s’agissait d’une application différente, non listée dans les CVE mentionnées précédemment. Cela montre que toute application, même la plus anodine, peut très bien fragiliser l’ensemble du système.

6. Pour aller plus loin…

Dans le cadre d’un test d’intrusion, le scénario d’exploitation décrit plus haut présente un inconvénient de taille : la machine doit être redémarrée. Or l’un des principaux objectifs d’une élévation de privilèges en local sur un serveur Windows est d’extraire les mots de passe grâce à l’excellent outil Mimikatz [7] pour éventuellement obtenir celui d’un administrateur du domaine. Le problème est que, lors du redémarrage, ils sont effacés de la mémoire.

Si le mode de démarrage du service IKEEXT est « automatique », nous ne pourrons pas y faire grand-chose. En revanche, dans sa configuration par défaut sous Windows Server 2008 R2, il est en mode « manuel » et donc non démarré à l’initialisation du système. Par conséquent, si nous parvenons à le déclencher depuis une session déjà ouverte, le code d’exploitation fonctionnera sans que le redémarrage complet du serveur ne soit nécessaire.

Fig. 3 : État du service IKEEXT sous Windows Server 2008 R2.

Il existe en fait une méthode assez simple pour parvenir à cette fin. Rappelons-nous que ce service est utilisé lors de la création de tunnels VPN IPSec. Or nul besoin d’être administrateur local pour établir un tel tunnel. En théorie, nous devrions pouvoir démarrer ce service en créant une simple connexion VPN.

Cette opération s’effectue depuis le « Centre Réseau et partage », en cliquant sur le lien Configurer une nouvelle connexion ou un nouveau réseau et en sélectionnant Connexion à un espace de travail. L’assistant affiche ensuite une fenêtre de configuration du profil. Nous allons simplement renseigner le champ Adresse Internet avec l’adresse IP de l’interface de bouclage : 127.0.0.1.

Fig. 4 : Configuration du profil VPN.


Dans la dernière fenêtre, nous rentrons un nom d’utilisateur et un mot de passe quelconques puis nous cliquons sur le bouton Se connecter. Windows va alors tenter d’initier la connexion, mais comme il n’y a aucun serveur VPN en écoute sur la machine, l’opération va bien évidemment échouer.

Après consultation de la console services.msc, nous observons que l’état du service IKEEXT est désormais « Démarré ». Cette technique a donc permis de le déclencher. Nous pouvons également observer une deuxième chose : le « Type de démarrage » est passé de « Manuel » à « Automatique ». Autrement dit, à partir de maintenant, il ne pourra être à nouveau exploité qu’en redémarrant complètement la machine.

Bien qu’efficace, cette méthode nécessite d’avoir un accès à l’interface graphique de la machine (grâce à une session « Terminal Services » par exemple). Or ce n’est pas toujours le cas, en particulier lors d’un test d’intrusion où l’on aurait obtenu un « reverse shell » par exemple. Nous allons voir que la même opération peut en fait être effectuée entièrement à partir d’une « invite de commandes ».

Les deux commandes suivantes permettent de constater que le service est arrêté (« STATE : 1 STOPPED ») et en mode de démarrage manuel (« START_TYPE : 3 DEMAND_START »).

La suite est similaire à ce qui a été décrit précédemment. Nous devons en effet créer un profil de connexion, mais cette fois-ci, il prendra la forme d’un fichier texte, que l’on nommera rasphone.pbk.

Une fois le profil de connexion créé, il ne reste plus qu’à l’utiliser à partir de l’outil « rasdial » en spécifiant son chemin avec l’option /PHONEBOOK.

Grâce à cette ligne de commandes, le système va tenter d’établir une connexion VPN à partir des paramètres fournis dans le fichier rasphone.bpk. Nous obtiendrons alors la même erreur que précédemment, mais le service IKEEXT aura bien démarré, ce qui était notre objectif.

Pour terminer, peu importe la méthode retenue puisqu’au final elles permettent toutes deux d’exécuter l’attaque sans passer par un redémarrage et donc de conserver l’état de la mémoire vive de la machine. Il ne reste alors plus qu’à récolter les mots de passe sur la machine fraîchement compromise.

Clément LABRO
Ingénieur sécurité chez NES

Références

[1] Dynamic-Link Library Search Order : https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx
[2] Microsoft Operating System Versions : https://msdn.microsoft.com/fr-fr/library/windows/desktop/ms724832(v=vs.85).aspx
[3] High-Tech Bridge Security Research Lab, Privilege Escalation Vulnerability in Microsoft Windows : https://www.htbridge.com/advisory/HTB23108
[4] Spiceworks : au moins une entreprise sur deux dans le monde utilise encore Windows Server 2003 : http://www.developpez.com/actu/101333/Spiceworks-au-moins-une-entreprise-sur-deux-dans-le-monde-utilise-encore-Windows-Server-2003-quels-systemes-serveur-utilisez-vous-en-entreprise/
[5] Suite d’outils « Sysinternals » : https://technet.microsoft.com/fr-fr/sysinternals/bb842062
[6] Windows 10 : la CNIL met publiquement en demeure MICROSOFT CORPORATION de se conformer, dans un délai de trois mois, à la loi Informatique et Libertés : https://www.cnil.fr/fr/windows-10-la-cnil-met-publiquement-en-demeure-microsoft-corporation-de-se-conformer-dans-un-delai
[7] Blog de Gentil Kiwi : http://blog.gentilkiwi.com/mimikatz

Retrouvez cet article (et bien d’autres) dans MISC n°90, disponible sur la boutique et sur la plateforme de lecture en ligne Connect !

Laisser un commentaire