Authentification interprotocolaire sous Windows et élévation de privilèges – Partie 1/2

Plusieurs vulnérabilités d’élévation de privilèges ont été découvertes sur les systèmes Windows ces derniers temps, reposant sur un même concept. Bien qu’elles aient été rectifiées, elles révèlent en réalité un problème bien plus profond, qui lui, n’est pas corrigé. En effet, la force d’interopérabilité entre les protocoles présents sous Windows en fait aussi sa faiblesse.

Depuis toujours, nombreuses sont les vulnérabilités d’élévation de privilèges sur Windows. Bien qu’en général celles-ci sont référencées dans la base de connaissances de Microsoft (Knowledge Base), il arrive que certaines vulnérabilités ne soient pas considérées en tant que telles, dans la mesure où, sous certaines configurations, l’exploitation ne fonctionnera pas.

C’est semble-t-il être le cas d’une vulnérabilité permettant à un utilisateur non privilégié d’obtenir les droits les plus hauts sur un système Windows, à savoir « AUTORITE NT\Système ». Cette vulnérabilité concernant initialement la version Windows 8, est en réalité une faille béante de sécurité pour les différentes versions de Windows ; et plus particulièrement affectant toutes les versions bureautiques, à savoir Windows 7, Windows 8 et même Windows 10 ! Les serveurs Windows, eux non plus ne sont pas en reste.

La vulnérabilité intitulée « Local WebDAV NTLM Reflection Elevation of Privilege » par son auteur James Forshaw du « Google Project Zero », est longtemps restée exploitable sur un Windows à jour et configuré par défaut. Malheureusement, malgré toutes les réponses de Microsoft à ce sujet, les systèmes de la firme semblent toujours autant vulnérables.

Cela fait en effet quelque temps que certaines vulnérabilités d’élévation de privilèges s’inspirent du ticket original publié sur le Projet Zero de Google [1].

La faille de sécurité remontée à l’époque ayant été mal interprétée, les vulnérabilités qui sont ensuite apparues ont été corrigées au cas par cas. Malgré tout, le fond du problème est toujours bel et bien présent.

Voici donc un retour technique sur cette vulnérabilité découverte il y a maintenant 2 ans …

1. Exploitation de la vulnérabilité

Le seul prérequis pour une exploitation réussie est de disposer d’une session non privilégiée sur un poste Windows configuré par défaut. L’attaque dont il est question se décompose en trois étapes :

  • création d’un serveur malveillant en local ;
  • authentification d’un service légitime auprès du serveur malicieux ;
  • utilisation de la session récupérée pour exécuter des actions sur le système.

1.1 NTLM dans SMB : détournement d’une authentification NTLMSSP

Le détournement de protocoles d’authentification est un aspect courant des vulnérabilités de type élévation de privilèges sur Windows.

Une des possibilités pour obtenir une session sur le système est de passer par la négociation NTLM. Ce mécanisme d’authentification peut être utilisé dans de nombreux protocoles tels que HTTP, SMTP, POP3, DCE/RPC, SMB, et d’autres.

Dans ce cas précis, nous nous intéresserons au protocole SMB permettant d’interagir avec le système de fichiers d’une machine Windows. Effectivement, par défaut, Windows embarque un serveur SMB, lancé par le service « LanmanServer », écoutant sur le port 445. Enfin, ce protocole est largement documenté sur Internet, et plusieurs possibilités existent pour compromettre un système Windows en passant par cette interface.

Ainsi, dans l’éventualité où un attaquant parviendrait à intercepter des messages de négociation, il serait en mesure de les rejouer pour finalement établir une session avec le système affecté.

Comme documenté sur le site de Microsoft [2], l’intégration de l’authentification NTLM se fait grâce à un échange de paquets SMB, illustré par le schéma suivant :

Fig. 1 : Inclusion de l’authentification NTLM dans une session SMB.


L’authentification NTLM est un mécanisme basé sur l’échange de défis et réponses entre le client et le serveur. Pour obtenir une élévation de privilèges en passant par ce mécanisme d’authentification, il sera donc nécessaire de récupérer un échange authentique, et d’être transparent lors de l’exploitation afin de ne pas faire échouer l’établissement de session. Une fois la session SMB créée sur le système, l’attaquant pourra alors l’utiliser à sa convenance pour y exécuter des actions privilégiées.

Le principe d’élévation de privilèges étant exposé, il faut au préalable récupérer une authentification NTLM légitime. Pour ce faire, en admettant que l’attaquant dispose d’un serveur d’interception (détaillé dans la section « 1.3 Développement d’un serveur malveillant »), il est possible de déclencher des actions sur le système qui s’occupera alors de s’authentifier si on le lui demande. Par exemple, Windows est capable d’utiliser le protocole WebDAV, basé sur HTTP, pour s’authentifier en NTLM auprès d’un serveur, lorsqu’une ressource WebDAV a besoin d’être accédée.

1.2 Le service client WebDAV : WebClient

Le service « WebClient » est présent par défaut sur les systèmes bureautiques de Windows. Sur les versions serveur, il peut être installé, mais n’est pas livré par défaut. Ce service permet d’établir des connexions à des partages WebDAV, et c’est lui qui sera utilisé lorsque le système aura besoin d’accéder à un chemin représentant un partage WebDAV fictif.

WebClient est un service qui est arrêté par défaut et qu’un utilisateur ne peut normalement pas contrôler (ni démarrage, ni arrêt).

Fig. 2 : Tentative de démarrage du service en tant qu’utilisateur non privilégié.


En revanche, comme plusieurs autres services, il possède un déclencheur qui permet de demander le démarrage de ce service au Gestionnaire de Contrôle des Services (SCM) lorsque l’utilisateur en a besoin.

Cela permet donc à un utilisateur non privilégié de démarrer ce service s’il n’est pas déjà démarré, ce qui représente le point d’entrée pour cette vulnérabilité.

Le déclenchement d’un service par « trigger » se fait grâce à un identifiant qui peut être obtenu de la manière suivante :

Fig. 3 : Obtention du déclencheur du service Webclient.


Ce déclencheur est du type ETW (Event Tracing for Windows) et permet de démarrer le service en question lorsque le fournisseur spécifié recevra des évènements. En utilisant l’UUID récupéré, il est alors possible de déclencher le démarrage du service WebClient à l’aide de cet extrait de code source :


Afin d’exploiter la vulnérabilité, ce service sera utilisé pour la connexion au serveur malveillant. L’objectif de l’attaque est en effet de demander à un service s’exécutant en tant qu’« AUTORITE NT\Système » de venir se connecter, en passant par le protocole WebDAV, sur un serveur qui récupèrera alors les informations d’authentification.

1.3 Développement d’un serveur malveillant

Sur une machine Windows, un utilisateur non privilégié peut démarrer un serveur sur n’importe quel port non occupé, notamment en écoutant sur la boucle locale afin d’éviter tout blocage du pare-feu système.

Lorsqu’une connexion WebDAV sera établie sur le serveur ainsi lancé, celui-ci devra alors envoyer au client une demande d’authentification NTLM. Lors de l’échange (tout comme pour les attaques MITM), l’attaquant pourra alors transférer les messages clients à un service légitime Windows, et vice versa, afin de reproduire une négociation classique.

Le serveur malveillant aura alors à sa disposition une session établie avec le compte utilisé lors de l’authentification NTLM.

Voici un exemple mettant en œuvre un serveur HTTP dont le rôle est de transférer les échanges NTLM :

Fig. 4 : Messages d’authentification NTLM capturés et transférés au système.

1.4 Recherche d’un service déclencheur

Arrivés à ce stade, nous sommes prêts à nous emparer de n’importe quelle session d’authentification NTLM. Ainsi, plus la victime affectée aura des privilèges élevés, plus notre exploit nous donnera des accès.

Le déclenchement d’actions en tant qu’« AUTORITE NT\Système » sur un Windows est une recherche courante lors de l’exploitation de vulnérabilités permettant une élévation de privilèges. C’est notamment le cas pour les attaques d’usurpation de jetons (attaque basée sur l’emprunt d’identité sous Windows, autrement connue sous le nom d’« impersonation »).

Dans le ticket initialement publié, il est question d’utiliser la fonction de scan de fichiers présente nativement dans Windows Defender (à partir de Windows 8). Cette fonctionnalité est présente dans la bibliothèque MpClient.dll, contenue dans le répertoire d’installation du programme.

Effectivement, en requêtant le service « WinDefend » (qui est le service de Windows Defender), un utilisateur non privilégié peut déclencher un scan (et donc une connexion) sur la machine locale, en tant qu’« AUTORITE NT\Système », sur le répertoire de son choix. En spécifiant un fichier fictif présent sur le fameux serveur malveillant, il sera alors possible de capturer la session système qui effectuera une authentification NTLM lors de la connexion WebDAV.

Toutefois, cette fonctionnalité de Windows Defender n’existe pas sous Windows 7 et n’est pas disponible si le service est désactivé (ce qui arrive souvent lorsqu’une solution antivirus tierce est installée sur le système).

Afin de faire fonctionner l’exploit sur toutes les versions Windows, il est possible d’utiliser d’autres services, tournant en tant qu’« AUTORITE NT\Système », et cherchant à effectuer des opérations sur un fichier. Le seul critère limitant est le fait de pouvoir contrôler le chemin du fichier ouvert par le système. Néanmoins, il existe de nombreux services Windows remplissant ces conditions.

À titre d’exemple, il est possible d’utiliser la méthode de traçage des évènements pour des services Windows définis. En effet, la définition de cette configuration se fait dans la base de registre, qui sera alors contrôlée lorsque le service fonctionnera. La localisation de la clé concernée est la suivante : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\.

Par exemple, le service « IpHlpSvc » est au moins présent sur toutes les versions de Windows 7 à Windows 10 (également présent sur les versions Windows serveur). Ce service est démarré par défaut et va regarder régulièrement dans le registre la configuration de traçage pour ce service à l’emplacement suivant : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\IpHlpSvc\.

Fig. 5 : Configuration par défaut du traçage pour le service IpHlpSvc.


Christophe GARRIGUES
Ingénieur sécurité chez NES

La seconde partie de cet article sera publiée prochainement sur le blog, restez connectés 😉

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