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

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\ SmbServerNameHardeningLevelSignature SMB : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters\requiresecuritysignaturePar 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

 

Christophe GARRIGUES
Ingénieur sécurité chez NES

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