Envenenando los protocolos LLMNR y NBT-NS para obtener credenciales

En este post vamos a ver cómo sacar partida del comportamiento por defecto de Windows a la hora de usar el servicio de resolución de nombres. Lo primero entender cómo funciona el sistema, a la hora de resolver un nombre de dominio este es el orden en el que se “preguntará”:

1. DNS
2. LLMNR
3. NBT-NS

Teniendo esto en cuenta, si en el punto 1 no obtiene un nombre de dominio, pasará al 2, y si no irá al 3. Cuando se hace uso de estos 2 últimos protocolos, cualquier Host que se encuentre en la red y conozca la IP por la que se pregunta podrá resolver, la respuesta dada puede ser legitima o no… 

Si hemos comprendido esto, en el ‘ataque’ que se mostrará a continuación, si el servicio lo ha podido resolver el DNS,  no pasará nada, pero por ejemplo, si queremos entrar al recurso compartido con nombre “temporal” e ingresamos “tmporal”, Windows pasará a usar los servicios de los cuales no nos podremos fiar, ya que pueden ser envenenados.

PoC

Para simular un pequeño ataque, se hará uso de la herramienta Responder (es necesario utilizar Python 2). Para saber cómo se usa esta herramienta, ejecuta python2 Responder.py --help:

Figura 1: Responder help

Para lanzar la herramienta se tiene que hacer con sudo. En el ejemplo se hace uso del siguiente comando: sudo python2 Responder.py -I eth0. Según van interactuando los usuarios en la red, si existe algún desliz nos llegará la IP, el nombre de usuario y su hash. En la siguiente captura se ve un Windows 10:

Figura 2: Responder funcionando con un Windows 10

Y en la siguiente una captura que afecta a un equipo con Windows 7:

Figura 3: Responder funcionando con un Widnows 7

Esta información se almacena en un fichero dentro de la carpeta logs. Cuando se tiene el Hash, se podrá echar mano a herramientas como John the Ripper para obtener la contraseña en texto plano.

Figura 4: Consultando el fichero generado por Responder

Si realizando un pentest, obtienes credenciales de un administrador de dominio de esta manera, … :) 

Hay más métodos, y que también nos permite lanzar esta herramienta, como hacer uso del protocolo WPAD, que se aprovechará de los navegadores que están configurados para detectar automáticamente los proxys, pero de ello no se va a hablar en este post.

¿Cómo podemos protegernos de este ataque?

Lo primero, para reducir el posible daño, los administradores de dominio deberían usar cuentas sin privilegios siempre que no necesiten de tales privilegios, pero la solución pasa por deshabilitar ambos protocolos, aunque en versiones antiguas de Windows se requiere tener activo NBT-NS.

¡Hasta el próximo post!