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 :
bool StartWebClientSvc()
{
REGHANDLE hReg;
bool success = false;
GUID WebClientSvcTrigger = { 0x22B6D684, 0xFA63, 0x4578,
{ 0x87, 0xC9, 0xEF, 0xFC, 0xBE, 0x66, 0x43, 0xC7 } };
if (EventRegister(&WebClientSvcTrigger, NULL, NULL, &hReg) == ERROR_SUCCESS)
{
EVENT_DESCRIPTOR eDesc;
EventDescCreate(&eDesc, 1, 0, 0, 4, 0, 0, 0);
success = EventWrite(hReg, &eDesc, 0, NULL) == ERROR_SUCCESS;
EventUnregister(hReg);
}
return success;
}
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.
Cette partie du registre est modifiable par tous les utilisateurs et permet de spécifier l’emplacement du répertoire où stocker les logs du service en question. Ainsi, grâce aux 2 valeurs suivantes, il est possible de faire interagir le service IpHlpSvc avec le serveur « pirate » précédemment créé :
- EnableFileTracing : 1 ;
- FileDirectory : \\127.0.0.1\tracing.
Le service tournant en tant qu’« AUTORITE NT\Système », viendra alors s’authentifier automatiquement auprès du serveur malveillant, qui s’occupera ensuite de dialoguer avec le système en transférant les messages d’authentification reçus.
La session SMB sera alors établie sur le système, et les privilèges obtenus seront ceux du service (le serveur ayant relayé les paquets NTLM légitimes).
1.5 Passage de l’élévation de privilèges à l’exécution de code
Le POC publié est développé en Java, car la bibliothèque jCIFS offre une implémentation du protocole SMB complète et permet donc de modifier librement le mécanisme d’authentification, afin d’y injecter les messages de négociation NTLM reçus par le système. Avec une implémentation CIFS en C/C++ (cf. le projet samba) par exemple, il est possible de se défaire de cette dépendance à Java qui n’a donc plus besoin d’être installé pour l’exploitation.
De plus, l’exploit publié permet seulement de créer un fichier texte, mais il est bien évidemment possible d’aller plus loin notamment en communiquant avec le gestionnaire de services Windows, en passant par le protocole SMB. Cela permet alors de créer un service (si le compte obtenu est suffisamment privilégié) pour exécuter n’importe quelle commande en tant qu’« AUTORITE NT\Système ».
En effet, sur les machines Windows il existe par défaut un canal nommé \PIPE\svcctl permettant d’interagir avec le gestionnaire de services. Il s’agit en réalité d’une interface honorant des communications RPC (Remote Procedure Call) encapsulées dans des paquets SMB :
Fig. 6 : Création de service en passant par l’interface SVCCTL à travers SMB.
Après la création du service malveillant et son exécution, il est alors possible d’exécuter n’importe quelle commande dans le contexte de l’utilisateur « AUTORITE NT\Système ».
Enfin, pour obtenir un mode interactif, il est possible d’intégrer dans l’exploit l’outil PAExec (qui est l’équivalent de PSExec en version « logiciel libre ») [3]. Le fait d’ajouter cette partie post exploitation permet ensuite de lancer simplement les programmes de manière interactive, en tant que système sans avoir à redévelopper la partie interactivité sur la station Windows avec le compte système local.
2. Protections contre l’attaque
2.1 Durcissement du protocole SMB
Afin d’éviter cette attaque, il existe deux contre-mesures possibles, basées sur le durcissement du protocole SMB. Néanmoins, ces paramètres ne sont pas configurés par défaut :
- Selon Microsoft, en activant la validation du SPN (Service Principal Name) ou en activant la signature sur les paquets SMB. Attention : dans un contexte d’entreprise, cela peut causer des dysfonctionnements avec les services et applications déjà existants.
Validation SPN : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters\ SmbServerNameHardeningLevel
Signature SMB : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters\requiresecuritysignature
Par défaut, SmbServerNameHardeningLevel et requiresecuritysignatureest sont à 0. Dès lors que l’une des valeurs passe à 1, le système refusera l’accès lors de l’authentification établie par les paquets SMB SessionSetupAndX.
- Plus radical : si les utilisateurs n’ont pas besoin d’accéder à des partages WebDAV, le fait de désactiver le service « WebClient » empêchera un attaquant de pouvoir passer par ce point d’entrée pour exploiter la vulnérabilité.
Dès lors, durant les tests d’intrusion menés chez divers clients, il a fallu faire la chasse aux mauvaises configurations SMB, et ce notamment sur les postes de travail. Dans la majorité des cas, les systèmes audités étaient vulnérables. Cela s’explique par le fait que SMB est un protocole couramment utilisé dans un contexte d’entreprise et que les administrateurs sont assez frileux de ce genre de durcissement.
2.2 Sortie d’un correctif officiel
C’est seulement en juin 2016 que Microsoft a fini par apporter un correctif comblant cette faille de sécurité. En effet, sans connaissance de plus de détails, lors du transfert du message d’authentification NTLM, il semble que l’authenticité de l’émetteur est désormais contrôlée, invalidant alors la vulnérabilité en passant par SMB.
Cette correction tardive a laissé pendant plus d’un an et demi une faille béante dans tous les systèmes Windows disposant de ce fameux service WebClient. En consultant le bulletin de sécurité MS16-075, il apparaît également que Microsoft est un peu présomptueux quant à la « non-exploitation » publique de cette faille (le code ayant été publiquement révélé) [4].
3. Et maintenant … ?
Il semble malheureusement que Microsoft soit passé à côté des réelles causes de cette faille. En sécurisant le protocole SMB, la firme de Redmond a effectivement fermé une des portes d’entrée. Ceci dit, comme évoqué dans le ticket du Projet Zero de Google, d’autres protocoles supportent l’authentification NTLM, et ils sont nombreux.
L’un d’entre eux, le protocole RPC (comme vu précédemment), est extrêmement intéressant puisque de nombreuses interfaces RPC sont disponibles sur n’importe quelle station Windows. Le port TCP 135 représente en effet le cartographe des points de terminaison RPC. C’est en passant par cette interface, qu’il est alors possible d’énumérer les différentes interfaces RPC disponibles sur le système. En exécutant l’outil « portqry » développé par Microsoft, on obtient alors une longue liste qui donnera ensuite des idées à certains pour exécuter du code :
Fig. 7 : Aperçu des interfaces RPC disponibles sous Windows.
Comme on peut le constater sur la Figure 7, il existe au moins 2 types de services RPC en écoute sur la machine : ceux communiquant en passant par les canaux nommés (ncacn_np) et les autres utilisant les sockets TCP (ncacn_ip_tcp). En réalité, il existe plusieurs autres protocoles permettant le transport des RPC (dont UDP et HTTP).
En réutilisant le principe de l’exploit communiquant en SMB, et en l’appliquant à un autre protocole de transport, il est alors sûrement possible d’obtenir une élévation contournant ainsi le correctif apporté.
Conclusion
Les systèmes Windows embarquent de nombreux protocoles. Lorsqu’une vulnérabilité affecte un mécanisme aussi conceptuel que l’authentification universelle pouvant être embarquée dans divers protocoles, il est recommandé de ne pas le traiter au cas par cas et de corriger le problème en amont.
D’ici à ce que soit appliqué un contrôle de sécurité réellement efficace, les systèmes Windows peuvent être compromis par des pirates ayant accès à des machines, que ce soit à distance ou physiquement. À ce jour, la solution la plus efficace pour éviter ce type d’attaques reste de désactiver le service WebClient, bien que cela puisse engendrer des effets de bords dommageables dans le contexte d’une entreprise…
Remerciements
James Forshaw pour ses travaux de recherche de qualité
Nicolas Canovaz pour son appui lors du développement des exploits
Clément Labro pour sa relecture attentive
Références
[1] Ticket de sécurité officiel sur la vulnérabilité WebDAV, par James Forshaw : https://code.google.com/p/google-security-research/issues/detail?id=222
[2] Encapsulation du NTLM dans SMB : https://msdn.microsoft.com/en-us/library/cc669093.aspx
[3] Site officiel de l’outil PAExec : https://www.poweradmin.com/paexec/
[4] Bulletin de sécurité corrigeant la vulnérabilité SMB, MS16-075 : https://technet.microsoft.com/en-us/library/security/ms16-075.aspx