Authentification interprotocolaire sous Windows et élévation de privilèges

Magazine
Marque
MISC
Numéro
90
|
Mois de parution
mars 2017
|
Domaines


Résumé
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.

Body

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 :

ntlm_over_smb

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).

webclient_access_denied

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 :

webclient_qtriggerinfo

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 :

authentication_messages

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\.

regedit_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 :

create_service

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 :

rpc_interfaces

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


Sur le même sujet

Surveillance des accès de production en télétravail

Magazine
Marque
MISC
Numéro
111
|
Mois de parution
septembre 2020
|
Domaines
Résumé

Il est courant de protéger l'accès aux infrastructures de production au travers de VPN ou de bastions SSH, et beaucoup d’organisations limitent encore ces points d'entrée à leur infrastructure interne. Lorsque l'organisation passe en mode télétravail à 100%, il faut forcément permettre l'accès depuis des adresses IP arbitraires, et se pose alors la question de surveiller ces accès pour détecter et bloquer rapidement une tentative d'accès malveillante.

Utilisez Terraform pour vos projets Docker

Magazine
Marque
GNU/Linux Magazine
Numéro
240
|
Mois de parution
septembre 2020
|
Domaines
Résumé

Terraform est un outil populaire pour déployer de l’infrastructure en particulier à destination des Clouds publics. Cependant, il possède de nombreux providers pour dialoguer avec différents hyperviseurs, bases de données ou solutions d’infrastructures en Software Defined. Voyons dans cet article son utilisation avec Docker.

Sécurisation du serveur

Magazine
Marque
Linux Pratique
HS n°
Numéro
48
|
Mois de parution
septembre 2020
|
Domaines
Résumé

Notre serveur RHEL est désormais fin prêt à être utilisé et maintenu, sans peine et de manière confortable. Cependant, notre travail n’est pas terminé. Il nous reste encore un élément crucial à valider : nous assurer que le serveur est aussi sûr et protégé que possible face à un éventuel assaillant mal attentionné.

Introduction au dossier : Télétravail : comment ne pas sacrifier la sécurité ?

Magazine
Marque
MISC
Numéro
111
|
Mois de parution
septembre 2020
|
Domaines
Résumé

Le dossier du précédent numéro traitait du concept de « Zero Trust ». Le numéro actuel est en quelque sorte une suite logique : nous passons d’un idéal où l’accès distant est possible « par design », à une réalité où il a fallu faire des choix fonctionnels et être conciliant avec la sécurité.

Supervision des architectures à microservices avec Prometheus

Magazine
Marque
Linux Pratique
Numéro
121
|
Mois de parution
septembre 2020
|
Domaines
Résumé

Lorsqu’on supervise des services statiques, tel qu’un serveur apache ou un serveur de base de données, on se concentre sur le bon fonctionnement de ces derniers (réponse aux requêtes, état : démarré ou non...) et donc un outil de supervision est nécessaire pour évaluer le statut du service en question. Un outil comme Nagios est destiné à ce type de supervision. Mais si nos services sont susceptibles de disparaître à tout moment et sont remplacés par de nouvelles instances, comment pourra-t-on les superviser ? S’ils ne sont pas déployés sur leurs hôtes d’origine, comment peut-on les localiser dans ce cas ? Et si ces services sont sous forme de conteneurs, comment alors superviser les processus à l’intérieur de ces conteneurs ? Et enfin, si ces services sont déployés dans un orchestrateur à l’instar de Kubernetes, et donc sous forme de pod, comment superviser l’ensemble de ces pods repartis sur différents nœuds ? Dans cet article, nous répondons à toutes ces questions avec des cas pratiques. Mais voici déjà un indice concernant la réponse : Prometheus.

Tendance actuelle : la conteneurisation d'applications

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
110
|
Mois de parution
septembre 2020
|
Domaines
Résumé

Actuellement, il est fréquent de voir des applications proposées sous la forme d'un conteneur. Chaque mise en conteneur – ou conteneurisation – d'une application est particulière et j'ai justement dû récemment me plier à l'exercice : je partage avec vous mon expérience dans cet article.

Par le même auteur

Authentification interprotocolaire sous Windows et élévation de privilèges

Magazine
Marque
MISC
Numéro
90
|
Mois de parution
mars 2017
|
Domaines
Résumé
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.