Ataques MITM: ARP Poisoning y DNS Spoof con ARPSpoof

Esta vez comentaré prácticamente lo mismo pero realizando el ataque desde una terminal de forma manual, sin una GUI. Desde una distribución Kali Linux usando arpspoof y el plugin DNS_Spoof de Ettercap también desde la terminal.

El equipo atacante (KaliLinux) tendrá que "hacer de router" por lo que se tendrá que habilitar ip_forward para enrutar todo el tráfico que llegue a el. De modo que deje salir a la puerta de enlace original todo el tráfica de la víctima. Si esto no se hiciese la vícitma se daría cuenta de algo extraño sucede ya que se quedaría sin conexión a Internet.

Para este ejemplo el equipo atacante tendrá la dirección 192.168.100.20.

echo 1 >> /proc/sys/net_ipv4/ip_forward

Figura 1: Habilitar ip_forward para el enrutamiento de tráfico.

Usando Nmap lanzamos un escaneo de reconocimiento a toda la red local disponible en este caso una clase C CIDR /24.

Para este ejemplo la víctima será la 192.168.100.10.

nmap -sP [DIRECCIÓN_RED/CIDR]

Figura 2: Escaneando toda la red local con Nmap.

Envenenamos la tabla ARP del equipo atacado y le hacemos creer qu ela dirección MAC verdadera del equipo atacante (192.168.100.20) es la misma que la de su puerta de enlace (router: 192.168.100.1). Inicio del ataque, especificamos la interfaz de salida con -i y con -t el target (víctima) seguido del equipo (router) en el que suplantaremos la dirección MAC para la víctima.

En la captura podemos ver como las direcciones MAC de la tabla ARP del equipo víctima (Windows) cambiaron después del ataque. La MAC del router es la misma que la del atacante.

Dejaremos esta terminal minimaza y siempre funcionando.

arpspoof -i [INTERFAZ_RED] -t [IP_VÍCTIMA] [IP_ROUTER]

Figura 3: arpspoof - Antes y después del ataque.

Empezamos a capturar tráfico en Wireshark desde el equipo atacante. Como ejemplo ingresaré en una web con mi nombre de usuario y contraseña. Este sitio no utiliza HTTPS, por lo que toda la información que veamos o ingresemos en un formulario no irá cifrada y será visible en texto claro.

Figura 4: Ingresando credenciales en un formulario de un sitio que no utiliza HTTPS.

Una vez interceptado HTTP el tráfico en Wireshark, podemos ver la solicitud POST de login. Examinado este paquete vemos el nombre de usuario y la contraseña en texto introducidos por la víctima.

Figura 5: Captura de credenciales introducidas por la víctima en el sitio web.

Iremos un paso más allá incorporando el plugin dns_spoof de Ettercap. Como se trata de redirigir las peticiones a direcciones DNS que solicite la víctima, crearemos una website (que puede ser una réplíca visualmente de un sitio web conocido: facebook.com, gmail.com, etc.).

Para ello crearemos un servidor HTTP con Apache. Creamos un documento HTML, en este ejemplo no replicaré ningún sitio ya que llevaría más trabajo y como prueba de concepto me basearé en la representación y entendimiento de la técnica más que en su elavoración.

Figura 6: Creación de un posible sitio web malintencionado.

Redirigimos las peticiones DNS a las direcciones IP que queramos en este caso al servidor Apache que estará sirviendo en la máquina del atacante.

Como ejemplo podemos redirigir las peticiones que vayan hacia google.es hacia una dirección IP correspondiente a otro sitio web que se verá más adelante, facebook.com y a este blog se redirigirán al servidor Apache del atacante.

Editamos el fichero del plugin "dns_spoof" de Ettercap.

/etc/ettercap/etter.dns

Figura 7: Editando fichero etter.dns para redirección de peticiones DNS de la víctima.

Una vez creado el documento principal y redirigido las peticiones DNS a la dirección IP de nuestro servidor, arrancamos el servicio del servidor Apache (ya instalado por defecto en Kali).

service apache2 start

Figura 8: Iniciar el servicio del servidor Apache

Lanzamos el plugin dns_spoof a través de ettercap haciendo uso de la terminal. Estando la terminal de arpspoof funcionando. Abrimos una nueva terminal para ejecutar lo siguiente.

ettercap -T -q -i [INTERFAZ_RED] -M arp:remote -P dns_spoof //[IP_ROUTER]// //[IP_VÍCTIMA]//

Figura 9: Ejecución del plugin dns_spoof de Ettercap en la terminal.

Si observamos las siguientes capturas de pantalla, vemos como el cliente intenta acceder a facebook.com y este lo redirige a nuestro servidor Apache.

Es curioso que siendo sitios webs bien conocidos y que de forma automática redirigen estas solicitudes a conexiones HTTPS y no HTTP. Pero en ciertas ocasiones y también dependiendo de como tengamos de limpio los navegadores webs tanto en IE como Firefox en ambos casos redirigieron estas solicitudes a donde se esperaba.

En la mayoría de ocasiones esto no fue posible mostrarlo tal cual aparecen en las capturas, ya que como ya dije al final del post de la parte 1 existen técnicas (HSTS y HPKP) que evitan que esto pase así como tampoco sería efectivo con SSLStrip el cual veremos en una futura entrada de este blog.

De manera que en la gran mayoría de ocasiones (no en todas) tuve que forzar la petición por "HTTP://facebook.com" en la barra de direcciones del navegador. Estos sitios web están configurados para redireccionar de forma automática sus solicitudes HTTP a HTTPS. Aunque se acceda por algún enlace o se escriba solamente "facebook.com" estas webs siempre intentarán redirigir a su sitio seguro y comprobar su certificado.

En el caso de este blog al no disponer de HTTPS y menos de un certificado de confianza, vemos que no existe ningún problema en redirigir tráfico HTTP.

En el último caso la redirección de google.es hacía la dirección IP establecida vemos que ha funcionado. Lo cual no siempre fue así de las pruebas realizas, por la misma razón que comenté anteriormente, la redirección HTTP a HTTPS.

Figura 10: Redirección de facebook.com hacia el servidor Apache del atacante.

Figura 11: Redirección de es.es.facebook.com hacia el servidor Apache del atacante.

Figura 12: Redirección de zonasystem.com al servidor Apache del atacante.

Figura 13: Redirección de google.es hacía la dirección IP establecida en etter.dns.

Con nslookup vemos la comprobación de redirecciones DNS en el equipo atacado. En este caso facebook.com redirige al servidor Apache del equipo atacante.

Figura 14: Comprobando las redirecciones DNS en el equipo atacado.

En próximas entradas comentaré para que como sirve y como usar SSLStrip. Las desventajas que actualmente existen y que posibilidades de redirigir tráfico HTTPS hacia HTTP.

Saludos!