Protocoles NBT-NS, LLMNR et exploitation des failles

Posted On 26 août 2018

Protocoles NBT-NS, LLMNR?

Link-Local Multicast Name Resolution (LLMNR) et Netbios Name Service (NBT-NS) sont deux composants présents en environnement Microsoft. LLMNR a été introduit dans Windows Vista et est le successeur de NBT-NS.

Ces composants permettent d’aider à identifier des hôtes sur le même sous-réseau lorsque les services DNS centraux échouent. Ainsi, si une machine tente de résoudre un hôte particulier, mais que la résolution DNS échoue, la machine tentera alors de demander à toutes les autres machines du réseau local la bonne adresse via NBT-NS ou LLMNR :

• NBT-NS est basée sur l’identification par le nom NetBIOS – Utilise le port TCP 137
• LLMNR est basé sur le format DNS (Domain Name System) – Utilise le port UDP 5355

Historiquement, Microsoft et Apple ont proposé comme standards leurs propres protocoles en se basant sur Multicast Domain Name Service: Microsoft a développé LLMNR et Apple mDNS. La différence majeure entre les deux protocoles se situe au niveau de la gestion des noms de domaine. Là où mDNS n’autorise que des noms de domaine sur l’espace « .local. », LLMNR ne filtre pas et autorise tous les noms de domaine (nous verrons par la suite que cela peut poser un réel problème de sécurité). LLMNR n’a pas réussi à s’imposer comme standard. Le protocole mDNS est beaucoup plus largement utilisés que LLMNR.

Pourtant LLMNR ou NBT-NS (aussi obsolète) sont très utilisés dans Windows. mDNS a également été implémenté à partir de Windows 10, mais son utilisation est limitée à la découverte d’une imprimante en réseau.

Recherche de noms sur le réseau

Quand un client recherche un nom sur le réseau il effectue sa recherche en plusieurs étapes et attend une réponse d’un service distant. Prenons un exemple, je recherche le partage réseau \\srvinconnu
Windows va effectuer les recherches via plusieurs mécanisme pour tenter de trouver \\srvinconnu

• Recherche en utilisant le HOST  local de la machine (C:\Windows\System32\drivers\etc\hosts);
• S’il ne trouve rien: recherche dans le cache DNS local (ipconfig /displaydns);
• S’il ne trouve rien: recherche dans le/les DNS configuré(s) dans la carte réseau;
• S’il ne trouve rien: recherche NetBIOS  en utilisant NBT-NS et en broadcastant le subnet;
• Si personne ne lui répond: recherche en utilisant LLMNR et en diffusant sur l’adresse multicast;
• Si personne ne lui répond: échec de la recherche. Partage réseau introuvable.

Nous pouvons voir les 3 étapes avec une analyse de trame ci dessous (les 2 premières étant locales, elles ne s’affichent bien évidement pas):
-> DNS (Requête vers le serveur DNS 192.168.0.104 : name srvinconnu.test.local)
-> NBTNS (Diffusion vers adresse de broadcast de mon sous réseau 192.168.0.255)
-> LLMNR (Diffusion vers les adresses de multicast IPv4: 224.0.0.252 et Ipv6:  FF02::1:3)

En complément d’information: LLMNR supporte IPv6; NBT-NS ne supporte que IPv4

 

Exploitation des failles

Ces protocoles semblent inoffensifs, en théorie… Il ne sont là que pour faciliter la vie les utilisateurs et leur permettre d’accéder aux ressources sans configuration complexe. Malheureusement, cela ouvre une vulnérabilité majeure que des personnes mal intentionnées peuvent utiliser pour obtenir des informations d’identification complètes d’utilisateurs.
Un attaquant pourrait librement écouter sur un réseau les diffusions LLMNR (UDP / 5355) ou NBT-NS (UDP / 137) et y répondre, en prétendant que l’attaquant connaît l’emplacement de l’hôte demandé (Poisoning). Cette réponse contiendrait l’adresse IP d’un serveur malveillant qui disposerait d’une fonction de collecte de valeur d’identification (comme les hashs NTLMv1/v2  par exemple).

C’est justement ce scénario que nous allons maquetter ci après. Nous verrons aussi d’autres type d’attaque par ce mécanisme et comment s’en protéger.

Responder

L’outil utilisé pour ces attaques est Responder mais Metasploit de Rapid7 a aussi un module qui permet d’effectuer la même chose (auxiliary/spoof/llmnr/llmnr_response).

Responder est un outil « multithread » permettant de répondre à des requêtes IPv4 LLMNR et NBT-NS pour mener des opérations de poisoning de manière automatique. En plus de ces fonctions de poisoning, on y retrouve également des serveurs Rogue disposant d’une fonction de collecte des valeurs de hachage NTLMv1/v2 ou dans certain cas le mot de passe en clair.

Attaque SMB

 

Ce type d’attaque consiste pour l’attaquant à écouter sur le réseau les diffusions LLMNR ou NBT-NS, et répondre quand un client essaye de se connecter à un serveur qui n’est pas connu du DNS. Cela signifie pour le client qu’il faut qu’il essaye de se connecter à un serveur inexistant ou pour lequel il se trompe d’orthographe. Par exemple \\SVR01 au lieu de \\SRV01 ou dans notre cas \\SRVINCONNU:

Vue coté attaquant (avec l’outil Responder en écoute)

 

Vue coté poste client (Analyse de trame):

Nous pouvons constater ci dessus que le client (192.168.0.101) tente de résoudre par tout moyen \\SRVINCONNU, jusqu’à ce que Responder intercepte une requête et y réponde. Il va même y répondre avec les 2 protocoles LLMNR et NBTNS.  A présent notre Client sait que \\SRVINCONNU correspond à l’adresse IP 192.168.0.1 (notre serveur rogue). Ce dernier est en écoute sur le port TCP 445 (SMB) et va donc se faire passer pour un serveur légitime. Nous voyons dans la dernière trame ci dessus, que le client négocie le protocole d’authentification. Le serveur Rogue va lui indiquer qu’il ne supporte que des protocoles d’authentification « faible ». Le client étant autorisé à utiliser aussi ces protocoles d’authentification « faibles » va donc initier un processus d’authentification basé sur le protocole NTLM V2 et présenter au final son hash au serveur (« challenge-response » NTLM).

Attention: Il arrive souvent qu’il y ait des incompréhensions à ce sujet: 
Les hashs Net-NTLM (alias NTLM V2 dans l’exemple ci dessus) sont utilisés pour l’authentification. Ils sont dérivés d’un algorithme challenge / réponse et sont basés sur le hash NT de l’utilisateur. Le Hash NT de l’utilisateur se trouve dans la base NTDSI.dit présente sur les contrôleurs de domaine ou dans la base SAM d’un ordinateur client d’un domaine et chargé en mémoire par le processus LSASS.

Ce hash NTLM V2 est utilisable dans le cadre d’une attaque par Relay (via les scripts pythons ntlmrelayx.py ou MultiRelay.py qui est présent avec la suite Responder). Ce hash peut être aussi bruteforcé moyennant du temps processeur afin de trouver le mot de passe en clair.
Par contre, il ne pourra pas être utilisé dans des attaques Pass-The-Hash (Mimikatz) car c’est le hash NT qui est nécessaire dans ce cas).

L’exemple ci dessous montre une recherche du hash par dictionnaire en utilisant JohnTheRipper):

A noter que le serveur SMB exécuté par Responder supporte l’ensemble des systèmes de type Microsoft Windows allant de la version NT4 jusqu’à Windows Server 2012 RC. Le système d’exploitation mac os x Mojave fait également partie de la liste des systèmes supportés par le serveur SMB de Responder, au même titre que tous les systèmes utilisant la solution Open Source Samba.

 

Attaque WPAD

Le protocole WPAD (Web Proxy Auto-Discovery Protocol) est une méthode utilisée  les navigateurs pour localiser l’URL d’un fichier de configuration. Une fois la détection et le téléchargement du fichier de configuration terminés, il peut être exécuté pour déterminer le proxy pour une URL spécifiée.

Encore une fois ce mécanisme est implémenté pour faciliter la configuration des navigateurs WEB et c’est cette simplification qui va se retourner contre ce protocole.

Par défaut le navigateur IE active cette recherche WPAD. Chrome et Firefox utilisent les paramètres systèmes et donc sont aussi concernés!

Configuration de ce paramètre sous Windows 10:

Le principe est simple, si le navigateur est configuré pour détecter automatiquement la configuration du proxy, il essayera de télécharger le fichier : wpad.<domaine_local>/wpad.dat ou le fichier proxy.pac.

Voici un exemple très simple d’un wpad.dat qui indique au navigateur la route qu’il doit utiliser pour accéder à un site:

Voici comment le poste de travail tente de résoudre WPAD en temps normal.

Sur un réseau d’entreprise, une entrée DNS (Type A) «wpad» doit donc être créé. Comme pour un partage SMB, si cette requête DNS échoue, le client utilise nos protocoles maintenant bien connus LLMNR ou NBT-NS  pour résoudre «wpad».

C’est à ce moment que Responder entre en service; Il intercepte la requête et y répond en indiquant que l’adresse IP du WPAD est le serveur de l’attaquant. WPAD vient alors récupérer un fichier de configuration pour le navigateur que Responder a spécialement forgé:

Contenu complet du WPAD:

Ce fichier indique au navigateur que tout le flux doit passer par PROXYSRV qui est en fait lui même. Un service web HTTP imposant une authentification BASIC est en écoute. Le client est alors invité à saisir son login et mot de passe, celui ci sera donc capturé par le serveur rogue et le client redirigé vers Internet. Responder nous affiche alors en clair les informations d’identification de l’utilisateur:

 

A savoir: Dynamic DNS est activé par défaut dans un environnement Active Directory avec DNS intégré. Quand un client intègre un ordinateur au domaine, une entrée DNS correspondant au nom de sa machine est aussi créée. Nous pourrions imaginer qu’un client malintentionné intègre dans le domaine une machine nommée WPAD. L’entrée WPAD serait alors créée dans la zone DNS et le client pourrait se faire passer pour un serveur WPAD légitime. Dans un domaine d’entreprise, Microsoft a donc bloqué la résolution de cette entrée par défaut. La liste des entrées bloquées est consultable via la commande:

Pour activer WPAD dans une entreprise, un administrateur consciencieux, doit alors créer une entrée wpad (A) dans son DNS, et débloquer la résolution via la commande suivante:

Vous comprendrez donc que notre attaque Responder est possible tant que:

• Aucune entrée wpad n’est présente, même si wpad est bloqué par les DNS
• Aucune entrée wpad n’est présente et si wpad est débloqué par les DNS

Limiter les attaques WPAD en entreprise

Pour limiter l’attaque WPAD, vous pouvez donc ajouter une entrée pour « wpad » dans votre zone DNS et bien sur la débloquer via la commande cité plus haut. Notez que l’entrée DNS n’a pas besoin de pointer sur un serveur WPAD valide. Tant que les requêtes sont résolues, l’attaque sera empêchée. Bien évidement une entrée correspondant à un véritable serveur WPAD est encore la meilleure idée 😉

Limiter les attaques WPAD hors entreprise

Décocher la case « Détecter automatiquement les paramètres de connexion » semble être le meilleur moyen pour un utilisateur de se protéger. Pourtant, plusieurs services et sous composants Windows n’utilisent pas les paramètres proxy WinINET définis dans IE et prennent aussi en charge la découverte automatique d’une configuration de proxy via son implémentation du protocole WPAD.

Les services sont les suivants:

• WinHttp-Autoproxy-Service
• MSDW
• Microsoft WNS
• MpCommunication
• NCSI
• Windows-Update-Agent
• Microsoft CryptoAPI

Contrairement aux idées reçues, il ne vaut mieux pas désactiver ces services. La méthode universelle mais néanmoins radicale est de créer une entrée wpad dans host local (C:\Windows\System32\drivers\etc\hosts) du client pointant sur la boucle locale 127.0.0.1. 

Afin de continuer à profiter de la configuration proxy, (ordinateur nomade qui se connecte à des réseaux « hostiles », ou ordinateur d’entreprise connecté à un réseau de confiance) il sera possible de fixer en « dur » le chemin FQDN du fichier proxy.pac ou wpad.dat:

Pour info: Certains services comme WinHttp-Autoproxy-Service sont configurable pour utiliser un proxy (netsh winhttp set proxy).

Se protéger complètement

Plusieurs solutions sont envisageable pour se protéger:
La 1ere, la plus radicale, mais la plus efficace est de désactiver ces protocoles sous Windows. Cela signifie que seul DNS sera utilisé pour la résolution.

Désactiver LLMNR:

• Ouvrez l’éditeur de stratégie de groupe locale: gpedit.msc
• Accédez à Stratégie de l’ordinateur local> Configuration ordinateur> Modèles d’administration> Réseau> Client DNS
• Sous Client DNS, positionnez l’option « Désactiver la résolution du nom de multidiffusion » sur Activé.
• Executer dans un cmd.exe ouvert en tant qu’administrateur la commande gpupdate /force pour appliquer cette nouvelle stratégie.

Ce paramètre est bien sur activable par GPO.

Désactivation NBT-NS:

• Ouvrez vos connexions réseau et affichez les propriétés de votre carte réseau.
• Sélectionnez Protocole Internet version 4 (TCP / IPv4) et cliquez sur Propriétés.
• Dans l’onglet Général, cliquez sur Avancé… et accédez à l’onglet WINS, puis sélectionnez « Désactiver NetBIOS sur TCP / IP ».

Attention, en ce qui concerne la désactivation de NBT-NS, la manipulation est a effectuer sur toutes les cartes connectées (Carte Wifi par exemple).
Il est aussi possible de désactiver de manière plus globale ce paramètre via DHCP en utilisant l’option « 001 Microsoft Disable Netbios Option » dans les Options du scope IP sous Avancé puis Microsoft Windows 2000 Options. Le paramètre à positionner est 0x2.

Enfin la commade powershell ci dessous permet de désactiver plus facilement sur l’ensemble des interfaces:

Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces\tcpip* -Name NetbiosOptions -Value 2