Le blog de Philippe

NetBT, LLMNR et mDNS

P.Leclercq dans Sécurité    2024-05-16   technologie 

article header image

Pourquoi désactiver NetBT, LLMNR et mDNS

J’ai encore récemment rencontré un cas où plusieurs de ces fonctionnalités étaient activées sur certains systèmes d’une entreprise. Voici donc un petit rappel.

Authentification NTLM

NTLM (New Technology LAN Manager) est une suite de protocoles de sécurité introduite par Microsoft avec Windows NT 3.1 pour garantir l’authentification, l’intégrité et la confidentialité des utilisateurs sur un réseau Windows. Il s’agit d’une ancienne technologie, largement remplacée par Kerberos lorsque les ressources appartiennent à un domaine Active Directory, mais elle est toujours utilisée dans les cas suivants :

  • Le serveur n’appartient pas à un domaine (c’est-à-dire qu’il fonctionne en mode groupe de travail) ;
  • Le serveur est un périphérique prenant en charge SMB, comme un NAS ou une imprimante réseau, et ne prend pas en charge Kerberos ;
  • Le serveur est dans un domaine, mais Kerberos ne peut pas être utilisé car
    • Le client s’authentifie avec son adresse IP, et non avec son nom DNS, et la résolution de nom inverse n’est pas disponible ;
    • Le client s’authentifie auprès d’un serveur situé dans une forêt différente, sans trust inter-forêts ;
    • Kerberos est bloqué au niveau du réseau (par exemple, par un pare-feu).

Lorsqu’un utilisateur connecté à un client a besoin d’un service d’un serveur, il est supposé être connu et disposer de certaines autorisations sur ce serveur. Cela signifie qu’il possède un compte reconnu par le serveur, représenté par un nom d’utilisateur et un mot de passe. Le hachage du mot de passe est conservé dans la base de données SAM.

Pour l’authentification, NTLM est un protocole de type challenge-response.

  1. Le client envoie un message NEGOTIATE_MESSAGE au serveur ;
  2. Le serveur répond par un message CHALLENGE_MESSAGE contenant une valeur aléatoire de 8 octets ;
  3. Le client répond par un message AUTHENTICATE_MESSAGE, contenant une valeur calculée en chiffrant le challenge et le hachage du mot de passe fourni par l’utilisateur.

Si la valeur envoyée par le client est égale à celle calculée par le serveur, cela signifie que le client connaît le hachage du mot de passe et que l’authentification réussit.

L’avantage de l’authentification NTLM est que le mot de passe lui-même n’est jamais transmis. L’inconvénient est que les fonctions de hachage et de chiffrement sont faibles par rapport aux normes actuelles et peuvent être facilement déchiffrées :

  • NTLMv1 utilise l’algorithme DES pour coder la réponse.
  • NTLMv2 utilise HMAC-MD5 pour hacher la réponse.

Il est désormais admis que tout mot de passe de 8 caractères peut être récupéré à partir d’un hachage NTLM en moins de 3 heures avec un ordinateur moyennement puissant.

NetBT

Description

NetBT, ou NetBIOS sur TCP/IP, est un protocole réseau permettant aux ordinateurs d’utiliser l’ancien protocole NetBIOS sur les réseaux IP. Développé au début des années 80, NetBIOS était destiné aux très petits réseaux locaux et n’était pas routable. NetBIOS fournissait trois services :

  • Service de noms (NBNS) sur les ports 137/udp et 137/tcp ;
  • Service de datagrammes sur le port 138/udp ;
  • Service de sessions (NBSS) sur le port 139/tcp.

Ce qui nous intéresse ici, c’est le service de noms. Pour trouver comment contacter un service par son nom, un client diffuse un datagramme de requête de nom, similaire à une requête DNS, et attend une réponse contenant l’adresse IP du propriétaire du nom.

Exemple

Supposons que nous ayons deux serveurs Windows :

  • WINSRV-LAB, adresse IP 10.0.0.25
  • WINSRV2-LAB, adresse IP 10.0.0.26

Ils appartiennent à un groupe de travail, sans domaine, et ne sont pas enregistrés dans le DNS. NetBT est activé. Sur WINSRV-LAB, un partage réseau appelé SHARE a été configuré et est accessible à un utilisateur appelé remoteuser.

Si je vais sur WINSRV2-LAB et que je saisis la commande suivante :

net use Z: \\WINSRV-LAB\SHARE /u:remoteuser *

WINSRV2-LAB essaie d’abord de résoudre le nom via DNS, mais comme les serveurs ne sont pas enregistrés dans DNS, il ne reçoit aucune réponse et se rabat sur NetBT pour résoudre l’adresse de WINSRV-LAB.

Voici une capture d’écran du début du dialogue :

Requête NetBT

On peut clairement voir :

  • la requête DNS (de 10.0.0.26 à 10.0.0.254, le serveur DNS) ;
  • la réponse DNS (négative) ;
  • la requête de broadcast NBNS (de 10.0.0.26, port UDP 137 à 10.0.0.255, adresse de broadcast, port UDP 137) ;
  • la réponse NBNS de WINSRV-LAB (de 10.0.0.25 à 10.0.0.26, également depuis/vers le port UDP 137).

À ce stade, WINSRV2-LAB connaît l’adresse de WINSRV-LAB. Nous pouvons le confirmer :

Commande NBTSTAT

Le reste du dialogue correspond à une authentification NTLM classique pour remoteuser, comme expliqué dans un paragraphe ci-dessus.

Exploitation de NetBT

Imaginez que je sois un attaquant désireux de voler les identifiants pour se connecter aux ordinateurs de ma victime. Je sais que si je capture un hachage NTLM, je peux probablement décoder le mot de passe. C’est encore plus simple si je propose le challenge moi-même. La question est : comment obtenir un hachage NTLM ?

Eh bien, un serveur proposant un partage recevra le hachage NTLM du client. Je vais donc prétendre offrir tous les partages possibles demandés par un client. Comment faire ? En écoutant toutes les demandes de noms NetBT et en répondant avec ma propre adresse, en espérant être plus rapide que le véritable propriétaire du partage, ou simplement en espérant qu’un utilisateur fasse une erreur de saisie dans un nom de partage pour lequel je serai le seul prétendant.
C’est ce qu’on appelle l’“empoisonnement de réponse”. Ceci est possible car NetBT ne dispose d’aucun mécanisme d’authentification ; n’importe qui peut revendiquer n’importe quoi sans vérification possible.

Des personnes courageuses ont développé un outil fantastique appelé responder, disponible sous Kali Linux.

Responder est capable d’écouter les requêtes de noms provenant de plusieurs protocoles (NetBT, LLMNR, mDNS), d’usurper les réponses et de capturer les hachages NTLM.

Voici une démonstration simple : la station de travail exécutant responder possède l’adresse IP 10.0.0.4.

Démarrons responder (mode verbeux, écoute sur l’interface eth0) :

sudo responder -I eth0 -v

Responder écoute maintenant sur le port 137/udp, prêt à répondre à toute requête NetBT.

──(plc㉿kaliVM)-[~/Documents]
└─$ sudo responder -v -I eth0
[sudo] password for plc: 
                                         __
  .----.-----.-----.-----.-----.-----.--|  |.-----.----.
  |   _|  -__|__ --|  _  |  _  |     |  _  ||  -__|   _|
  |__| |_____|_____|   __|_____|__|__|_____||_____|__|
                   |__|

           NBT-NS, LLMNR & MDNS Responder 3.1.4.0

  To support this project:
  Github -> https://github.com/sponsors/lgandx
  Paypal  -> https://paypal.me/PythonResponder

  Author: Laurent Gaffie (laurent.gaffie@gmail.com)
  To kill this script hit CTRL-C


[+] Poisoners:
    LLMNR                      [ON]
    NBT-NS                     [ON]
    MDNS                       [ON]
    DNS                        [ON]
    DHCP                       [OFF]

[+] Servers:
    HTTP server                [ON]
    HTTPS server               [ON]
    WPAD proxy                 [OFF]
    Auth proxy                 [OFF]
    SMB server                 [ON]
    Kerberos server            [ON]
    SQL server                 [ON]
    FTP server                 [ON]
    IMAP server                [ON]
    POP3 server                [ON]
    SMTP server                [ON]
    DNS server                 [ON]
    LDAP server                [ON]
    MQTT server                [ON]
    RDP server                 [ON]
    DCE-RPC server             [ON]
    WinRM server               [ON]
    SNMP server                [OFF]

[+] HTTP Options:
    Always serving EXE         [OFF]
    Serving EXE                [OFF]
    Serving HTML               [OFF]
    Upstream Proxy             [OFF]

[+] Poisoning Options:
    Analyze Mode               [OFF]
    Force WPAD auth            [OFF]
    Force Basic Auth           [OFF]
    Force LM downgrade         [OFF]
    Force ESS downgrade        [OFF]

[+] Generic Options:
    Responder NIC              [eth0]
    Responder IP               [10.0.0.4]
    Responder IPv6             [fe80::78f1:152a:715b:d8e1]
    Challenge set              [random]
    Don't Respond To Names     ['ISATAP', 'ISATAP.LOCAL']

[+] Current Session Variables:
    Responder Machine Name     [WIN-Q4G97RPTM7I]
    Responder Domain Name      [PNA6.LOCAL]
    Responder DCE-RPC Port     [46020]

[+] Listening for events...

Je vais sur WINSRV2-LAB et lance la commande de montage de partage :

Commande NET USE

Après que j’ai saisi mon mot de passe, voici ce que responder affiche :

Capture du hash par responder

Bingo ! Il s’agit du paquet NTLMv2 contenant le hachage du défi et du mot de passe. Copions le hachage dans le fichier hash.txt et appelons John the Ripper à la rescousse :

Craquage du mot de passe par John

Victoire ! Le mot de passe de l’utilisateur distant est craqué !

La trace réseau indique que responder a contaminé le NBNS en envoyant sa propre adresse au serveur WINSRV-LAB dans le dialogue NTLM, capturant ainsi le message contenant le hachage du challenge et du mot de passe.

Capture réseau dialogue NetBT responder

Désactivation de NetBT

Pour désactiver NetBT :

Centre Réseau et partage -> Modifier les paramètres de la carte -> Double-cliquez sur la carte réseau -> Propriétés -> Protocole Internet version 4 -> Propriétés -> Avancé -> WINS -> Désactiver NetBIOS sur TCP/IP

Désactivation de NetBT

LLMNR

Description

LLMNR (Link-Local Multicast Name Resolution) est un protocole basé sur DNS qui permet la résolution de noms (traduction du nom d’hôte en adresse IP) pour les ordinateurs d’un même sous-réseau sans configuration d’un DNS central. Inventé par Microsoft, il est décrit dans la RFC 4795, mais n’a pas été adopté comme norme IETF.

Les hôtes participant au protocole LLMNR écoutent sur le port UDP 5355, à l’adresse multicast 224.0.0.252 (adresse MAC 01-00-5E-00-00-FC), et sur le port TCP 5355, à leur propre adresse IP. Lorsque l’un d’eux souhaite connaître l’adresse correspondant à un nom d’hôte, il envoie une requête, similaire à une requête DNS, à cette adresse multicast. La requête contient le nom à résoudre et le type d’enregistrement DNS souhaité (A pour IPv4, AAAA pour IPv6). L’ordinateur correspondant au nom demandé répond ensuite avec sa propre adresse IP, et le dialogue peut se poursuivre en pair à pair.

Exemple

En prenant le même cas d’utilisation que ci-dessus, voici la capture réseau du dialogue entre le client (WINSRV2-LAB, 10.0.0.26) et le serveur (WINSRV-LAB, 10.0.0.25) :

Capture réseau requete LLMNR

On peut clairement voir :

  • la requête DNS (de 10.0.0.26 à 10.0.0.254) ;
  • la réponse DNS (négative) ;
  • la requête LLMNR (de 10.0.0.26 vers l’adresse multicast 224.0.0.252, port 5355) pour l’adresse IPv4 (enregistrement A) de WINSRV-LAB ;
  • la requête LLMNR (de 10.0.0.26 vers l’adresse multicast 224.0.0.252, port 5355) pour l’adresse IPv6 (enregistrement AAAA) ;
  • la réponse LLMNR de WINSRV-LAB (de 10.0.0.25 à 10.0.0.26, depuis le port UDP 5355), avec son adresse.

Exploitation de LLMNR

Comme indiqué précédemment, responder empoisonne également les réponses LLMNR de la même manière que les réponses NetBT et capture les hachages NTLM. La cause est la même : absence d’authentification dans LLMNR.

Capture du hash par responder

Désactivation de LLMNR

Pour désactiver LLMNR, dans l’Éditeur de stratégie locale, accédez à Configuration ordinateur -> Modèles d’administration -> Réseau -> Client DNS, double-cliquez sur Désactiver la résolution de noms multidiffusion et sélectionnez Activé.

Désactivation de LLMNR

mDNS

Description

Le DNS multicast (ou mDNS) est un protocole permettant de convertir des noms d’hôtes en adresses IP sur un réseau local sans serveur DNS local. Le domaine DNS par défaut est .local. Il fait partie de la technologie zéro configuration. Il est implémenté dans les logiciels Apple Bonjour et Linux Avahi, ainsi que dans de nombreux appareils tels que les téléviseurs intelligents, les enceintes sans fil, les décodeurs… Sous Windows, sa prise en charge a débuté avec Windows 10. Il est décrit dans la RFC 6762.

Comme LLMNR, il utilise une adresse multicast (224.0.0.251) sur le port UDP 5353, avec l’adresse MAC 01:00:5E:00:00:FB.

Exemple

En prenant le même cas d’utilisation que ci-dessus, voici la capture réseau du dialogue entre le client (WINSRV2-LAB, 10.0.0.26) et le serveur (WINSRV-LAB, 10.0.0.25) :

Capture réseau requête mDNS

On peut clairement voir :

  • la requête DNS (de 10.0.0.26 à 10.0.0.254) ;
  • la réponse DNS (négative) ;
  • la requête MDNS (de 10.0.0.26 à l’adresse multicast 224.0.0.251, port 5353) pour l’adresse IPv4 (enregistrement A) de WINSRV-LAB ;
  • la requête MDNS (de 10.0.0.26 vers l’adresse multicast 224.0.0.251, port 5353) pour l’adresse IPv6 (enregistrement AAAA) ;
  • la réponse MDNS de WINSRV-LAB (de 10.0.0.25 vers 10.0.0.26, depuis le port UDP 5353), avec son adresse.

Exploitation de mDNS

Comme indiqué précédemment, responder empoisonne également les réponses mDNS de la même manière que les réponses NetBT et LLMNR, et capture les hachages NTLM de la même manière. La cause est la même : absence d’authentification dans mDNS.

Capture du hash par responder

Désactivation de mDNS

Pour désactiver mDNS :

  1. Ouvrez l’Éditeur du Registre Windows (regedit)
  2. Accédez à HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
  3. Créez une valeur DWORD EnableMDNS avec la valeur 0

Désactivation de mDNS

Etiquettes technologie 
Accueil   Début