Responder és una eina que escola el tràfic de la xarxa i respon els protocols LLMNR (Link Local Multicast Name) i NBT-NS (NetBIOS over TCP/IP Name Service) amb l’objectiu de capturar les credencials dels usuaris.

A més a més, amb Responder podràs crear servidors d’autenticació dels següents tipus per enganyar a l’usuari i poder així robar credencials NTLMv1, NTLMv2 i LM:

• SMB
• MSSQL
• HTTP
• HTTPS
• FTP
• POP3
• SMTP
• Proxy WPAD
• DNS
• LDAP

Protocols

Els ordinadors en una xarxa de directori actiu es comuniquen utilitzant els seus noms, per això és necessari realitzar una resolució de noms (DNS) per obtenir l’adreça IP.

El procediment és el següent:

1. El client obté l’informació del sistema i la configuració
2. Comprova la cache del DNS local
3. Si no hi ha informació a la cache, envia una petició al DNS
4. Si el DNS no sap la resposta, envia petició LLMNR.
5. Sinó, envia petició NBF-NS

LLMNR

El protocol LLMNR (Link Local Multicast Name) habilita la resolució de noms en escenaris on el DNS convencional no és possible. Degut a que LLMNR funciona només dins de la xarxa local, no es pot considerar un substitut del DNS.

S’utilitza el port TCP i UDP 5355 per peticions multicast (IPv4: 224.0.0.252 i IPv6: FF02:0:0:0:0:0:1:3)

NBT-NS

NetBIOS és una API que permet que els ordinadors d’una mateixa xarxa es puguin comunicar entre ells.

Hi ha tres tipus de serveis diferents:

• Name Service: s’utilitza per la resolució de noms. Opera el port 137 UDP.
• Datagram Distribution Service: s’utilitza per establir la comunicacions sense connexió. Opera al port 138 UDP.
• Session Services: s’utilitza per establir la comunicacions amb connexió. Opera al port 139 TCP.

Vulnerabilitat

Si els protocols LLMNR i/o NBT-NS estan habilitats i el DNS de la xarxa local no és capaç de realitzar la resolució de noms, l’ordinador llençarà una petició a tots els equips de la xarxa preguntant si algú sap resoldre la seva petició.

Qualsevol ordinador de la xarxa podrà respondre, encara que sigui amb informació invàlida.

Un exemple molt senzill és quan un usuari intenta accedir a una carpeta compartida però s’equivoca a l’escriure-la:

Capturant el tràfic amb WireShark, pots veure com el client envia peticions a Broadcast (IP .255). És a dir, a tots els equips de la xarxa:

Un possible escenari d’atac seria la següent:

1. L’usuari intenta accedir a la carpeta projectenadki, que no existeix.
2. El DNS respon indicant que no sap on troba el recurs.
3. Degut a que el DNS no ha sapigut resoldre la petició, el client ho pregunta a tots els equips de la xarxa.
4. L’atacant, que està escoltant el tràfic, captura la petició de resolució de nom i respon dient que ell si que té aquesta informació.
5. El client comença el protocol d’autenticació per a poder intercanviar l’informació.
6. L’equip atacant envia el repte.
7. El client envia el hash a la resposta, seguint el protocol d’autenticació NTLM.
8. L’atacant indica que l’autenticació ha fallat. Ha aconseguit el hash de la víctima.
9. L’atacant pot començar a crackejar el hash de la víctima.

Explotació

Per demostrar l’atac utilitzaré el sistema operatiu Kali Linux i l’objectiu serà aconseguir les credencials d’usuaris del domini. Per fer-ho, pots utilitzar l’eina anomenada Responder que està pre instal·lada a Kali, sinó també la pots instal·lar tu fàcilment.

Per iniciar Responder has d’indicar amb el paràmetre -I l’adaptador d’internet al que escoltar (pots obtenir l’informació amb ip addr):

responder –I ADAPTADOR

Una vegada executat, el programa es queda escoltant a la xarxa. Si un usuari intenta resoldre un recurs que no existeix, Responder interceptarà la comunicació i es farà passar per un ordinador que si que sap resoldre el recurs amb l’objectiu d’interceptar el hash:

El procés d’autenticació es realitza a través del protocol SMB. A aquesta captura de Wireshark pots veure clarament com la víctima (192.168.1.9) envia les peticions a Broadcast (192.168.1.255) preguntant pel recurs PROJECTENADKI. Tot seguit, l’ordinador atacant (192.168.1.42) li respon i inicien el procés d’autenticació a traves de SMB:

Post explotació

Responder guarda el resultat de l’atac, juntament amb els hashes a:

/usr/share/responder/logs

Els hashes NTLMv2 no es poden utilitzar directament en atacs de Pass the Hash. Per tant, hauràs d’aconseguir crackejar el hash per obtenir la contrasenya en text clar. Hi ha diverses eines que pots utilitzar:

• John the Ripper

john SMB-NTLMv2-SSP.txt –wordlist=/usr/share/wordlists/rockyou.txt

• Hashcat

hashcat -m 5600 SMB-NTLMv2-Client.txt /usr/share/wordlists/rockyou.txt

Mitigació

La recomanació per solucionar aquesta vulnerabilitat és molt senzilla d’implementar. Simplement s’han de deshabilitar els protocols.

• Inhabilitar a Windows: obrir l’editor de polítiques de grup local (gpedit.msc) i habilitar la característica Configuración del equipo > Plantillas administrativas > Red > Deshabilitar resolución de nombres de multidifusión.

• Inhabilitar a Windows a través del registre: obrir una CMD o PowerShell i executar aquestes dues comandes:

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

• Inhabilitar a Linux: editar el fitxer /etc/systemd/resolved.conf i modificar la linia LLMNR a No.

Detecció

Hi ha diverses maneres de monitoritzar la xarxa per prevenir un incident de seguretat:

1. Monitoritzar l’entrada HKLM\Software\Policies\Microsoft\Windows NT\DNSClient per detectar canvis a la característica EnableMulticast. Així no només sabràs si un atacant està modificant el registre, sinó que també indica que has estat compromès.
2. Monitoritzar el tràfic dels ports 5535 i 137 UDP. No hauries de capturar cap comunicació si els protocols estan deshabilitats.
3. Utilitzar eines d’spoofing de LLMNR/NBT-NS. Per exemple, podries tenir un Responder activat i monitorizar si rep alguna petició.

Referències

• Desactivar protocols: enllaç