Bienvenidos a este nuevo post, donde atacaremos dos protocolos de red ampliamente utilizados: el protocolo ARP y el protocolo DNS. Este es el primero de una serie de artículos en los que atacaremos protocolos de red que usamos a diario, pero que cuando fueron diseñados no se pensaron teniendo en cuenta la seguridad. En concreto, en este artículo veremos las debilidades del protocolo ARP y cómo estas permiten realizar un ataque de ARP Poisoning. Una vez realizado el ataque y habernos situado en medio de la comunicación con la máquina víctima, aprovecharemos esa posición para lanzar un ataque de DNS spoofing.
Protocolo ARP
La función del protocolo ARP es traducir una dirección IP a su dirección MAC. Dentro de una red interna, las comunicaciones entre equipos se realizan a nivel de capa 2 del modelo osi. A este nivel los equipos intercambian tramas y a diferencia de un paquete, en la cabecera de la trama se indica la dirección MAC del equipo con el que nos queremos comunicar. Es por ello que los equipos de la red interna necesitan conocer la dirección física del resto de equipos de la red: precisamente para poder comunicarse con ellos.
¿Cómo funciona el protocolo ARP ?
Para entender cómo funciona el protocolo ARP, veamos un ejemplo. Supongamos que un host se acaba de conectar a la LAN y necesita salir a Internet. Para ello tendrá que pasar por la puerta de enlace; supongamos que esta se encuentra en la IP 192.168.30.1. Para poder mandar un paquete a la puerta de enlace, el equipo necesita saber la MAC asociada a la IP 192.168.30.1.
Como el equipo se acaba de conectar, todavía no tiene ninguna entrada en su tabla ARP, por lo que realizará los siguientes pasos:
- Paso 1: manda un ARP request en broadcast, preguntando a toda la red qué equipo tiene la IP
192.168.30.1. - Paso 2: todos los equipos de la red reciben el ARP request, y el equipo
192.168.30.1responde con un ARP reply indicando cuál es su dirección MAC - Paso 3: el nuevo host recibe el ARP reply y añade la entrada en su tabla ARP.
Veámoslo con un ejemplo. Supongamos que el equipo 192.168.30.132 se ha conectado a la red, y desde el equipo 192.168.30.129 le lanzamos un ping.
Como el equipo 192.168.30.132 se acaba de conectar, el equipo 192.168.30.129 todavía no tiene la entrada en su tabla ARP.
Si ahora lanzamos el ping al equipo 192.168.30.132, como todavía no tenemos la entrada en la tabla ARP, tal y como se muestra en esta captura de Wireshark los dos primeros paquetes que se envían son:
- Paquete 1: ARP request en broadcast, preguntando quién tiene la IP 192.168.30.132
- Paquete 2: ARP reply, respondiendo con la dirección MAC asociada a la IP 192.168.30.132
Este protocolo, si bien funciona perfectamente, tiene un problema de diseño: no está autenticado. No existe ningún mecanismo que impida a un equipo responder a un ARP request aunque no sea el destinatario legítimo. Es decir, cualquier equipo puede responder a un ARP request aunque no estén preguntando por su IP, y si su respuesta llega antes que la del equipo legítimo, la tabla ARP de la víctima quedará envenenada. Esto es lo que se conoce como ARP Poisoning.
A esto se le suma un segundo problema de diseño: un equipo puede recibir ARP replies sin haber enviado previamente ningún ARP request, y aun así los aceptará.
Estos dos problemas de diseño serán la base para el ataque de envenenamiento de la tabla ARP (ARP Poisoning).
¿Qué es ARP Poisoning?
Tal y como vimos en el artículo de escaneo avanzado con nmap, el protocolo ARP no está autenticado y un equipo puede recibir ARP replies sin haber enviado ningún ARP request, un atacante puede envenenar la tabla ARP de una víctima enviándole masivamente paquetes ARP reply en los que suplanta a otro equipo de la red. De este modo, cada vez que la víctima se comunique con el equipo suplantado, todo el tráfico pasará por la máquina atacante. Veamos un ejemplo para entender el concepto.
Supongamos el siguiente escenario:
- Máquina atacante: IP: 192.168.68.56 MAC: aa-aa-aa-aa-aa-aa
- Máquina víctima: IP 192.168.68.57 MAC: bb-bb-bb-bb-bb-bb
- Puerta de enlace: IP: 192.168.68.1 MAC: cc-cc-cc-cc-cc-cc
Cuando un equipo quiere conectarse a Internet, ese tráfico necesita pasar por la puerta de enlace. Por tanto, como atacante, me interesa suplantar a la puerta de enlace, de manera que todo el tráfico que la víctima envíe hacia Internet pase primero por mis manos.
Para ello, aprovechando las debilidades del protocolo ARP, el atacante envía masivamente paquetes ARP reply a la víctima, diciéndole que la dirección MAC de la IP 192.168.68.1 es aa-aa-aa-aa-aa-aa. Así, la máquina víctima acaba teniendo en su tabla ARP la siguiente entrada:
192.168.68.1 -- aa-aa-aa-aa-aa-aa
192.168.68.56 -- aa-aa-aa-aa-aa-aaComo a nivel de red interna las cabeceras de las tramas llevan la dirección MAC, todo el tráfico que la máquina víctima envíe a la puerta de enlace estará pasando en realidad por la máquina atacante. Esto es lo que se conoce como Man in the Middle: el atacante se ha situado en medio de las comunicaciones entre la víctima y la puerta de enlace.
Una vez estamos en medio de la comunicación, podemos comprometer la disponibilidad de las comunicaciones (si no reenviamos el tráfico), o bien la integridad y la confidencialidad si se están usando protocolos de red no cifrados que exponen el contenido.
Veamos a nivel práctico cómo realizar el ataque de ARP Poisoning.
¿Cómo hacer un ataque de ARP Poisoning con Bettercap?
Para llevar a cabo el ataque, vamos a usar Bettercap. Antes de iniciarlo, la tabla ARP de la víctima contiene estas entradas (fijaos en que la MAC de la máquina atacante 192.168.68.56 y la de la puerta de enlace 192.168.68.1 son diferentes)
Con bettercap lanzamos el ataque usando el módulo arp.spoof:
set arp.spoof.targets 192.168.68.57
arp.spoof on
En esta configuración Bettercap realiza por defecto el spoofing sobre la víctima. Esto es suficiente para interceptar su tráfico saliente. Si quisiéramos situarnos en ambos sentidos de la comunicación, podríamos realizar un envenenamiento full-duplex, atacando también la tabla ARP de la puerta de enlace.
Podemos ver, como ahora en la tabla ARP de la víctima, la máquina atacante y la puerta de enlace tienen la misma MAC
Si abrimos Wireshark, podemos ver cómo se está llevando a cabo el ataque tal y como comentábamos: enviando ARP reply a la víctima diciéndole que la MAC de la puerta de enlace es la MAC de la máquina atacante.
De esta forma hemos realizado un ataque de envenenamiento de ARP y nos hemos situado en medio de las comunicaciones con la máquina víctima. Para demostrarlo, desde la máquina víctima (192.168.68.57) nos conectaremos a una web vía HTTP, y veremos que desde la máquina atacante podemos interceptar las credenciales que se envíen a través del formulario. Recordad que HTTP no va cifrado.
Desde la víctima, accedemos a este formulario vulnerable e introducimos unas credenciales
En la máquina atacante podemos ver los paquetes que la víctima (192.168.68.57) ha enviado al servidor web (44.238.29.244):
Como el tráfico es HTTP, podemos ver las credenciales que se han intercambiado:
DNS Spoofing
La función del protocolo DNS es resolver nombres de dominio a direcciones IP. Cuando nos queremos conectar a una web, por ejemplo mateujoanperello.com, nuestro navegador necesita traducir ese nombre a una dirección que pueda entender, es decir, a una IP. Para ello, antes de intercambiar paquetes con el destino, envía un paquete DNS al servidor DNS que tenga configurado, preguntándole cuál es la IP asociada a mateujoanperello.com. Una vez el servidor DNS le responde con la IP, ya puede empezar a intercambiar paquetes.
En esta captura de Wireshark se ve claramente cómo, al poner mateujoanperello.com en el navegador, lo primero que hace el equipo es obtener por DNS la IP asociada al dominio, y solo después realiza el intercambio de paquetes.
Aprovechando que con la técnica de ARP Poisoning nos hemos situado en mitad de la comunicación entre la máquina víctima y la puerta de enlace, podemos realizar un DNS spoofing. La clave está aquí: al estar en medio de la comunicación, las consultas DNS que la víctima envía pasan por nosotros, y si viajan sin cifrar podemos interceptarlas y responderle con la IP que nos convenga antes de que lo haga el servidor legítimo. No es necesario que la puerta de enlace sea el servidor DNS: basta con que la consulta atraviese nuestra posición de MITM.
Así, podríamos montar un ataque en el que, cuando la víctima se conecte a www.mibanco.com, en lugar de responderle con la IP legítima del servidor del banco le respondamos con la IP de un servidor donde tengamos alojada una página falsa, interceptando de esta forma sus credenciales.
¿Cómo hacer un ataque de DNS Spoofing con Bettercap?
Para montar el ataque, primero prepararemos una web falsa a la que redirigiremos a la víctima. Podríamos usar la suite Social Engineer Toolkit para clonar alguna página conocida, pero por simplicidad crearemos un pequeño index.html con una imagen y lo serviremos en el puerto 80:
Bettercap incorpora también la funcionalidad de DNS spoofing, así que, aprovechando el envenenamiento ARP que ya hicimos, especificamos el dominio que queremos suplantar, de manera que cada vez que la víctima visite instagram.com la redirijamos al puerto 80 de la máquina atacante:
set dns.spoof.domains www.instagram.com
set dns.spoof.address 192.168.68.56
dns.spoof on
Si ahora, desde la máquina víctima, accedemos a instagram.com, veremos cómo se muestra la página servida por el atacante:
A nivel de Wireshark podemos ver cómo, desde la máquina atacante, interceptamos la petición DNS en la que la víctima (192.168.68.57) solicita la IP de instagram.com y le respondemos con la IP del atacante:
Conclusiones
En este artículo hemos analizado los protocolos de red ARP y DNS, que utilizamos cada día. Hemos visto cómo, aprovechando que estos protocolos no fueron diseñados pensando en la seguridad, hemos podido envenenar la tabla ARP de la máquina víctima simplemente usando aquello que el propio protocolo nos permite hacer. Una vez envenenada la tabla ARP, nos hemos situado en medio de las comunicaciones entre la víctima y la puerta de enlace, lo que se conoce como un Man in the Middle.
Desde esa posición, y dado que las consultas DNS de la víctima pasaban por nosotros sin cifrar, hemos podido falsear la respuesta que resuelve instagram.com, redirigiéndola a un servidor bajo nuestro control.
Esto muestra también la importancia de usar protocolos seguros. En el momento en que introducimos cifrado, el atacante puede seguir situándose en medio de la comunicación, pero deja de poder aprovecharlo. Con HTTPS, aunque el tráfico pase por sus manos, las credenciales que la víctima envía viajan cifradas y resultan ilegibles. Con mecanismos de DNS cifrado como DoH o DNSCrypt, el atacante deja de poder inspeccionar o manipular directamente las consultas DNS. No obstante, esto no garantiza por sí solo que el dominio visitado quede completamente oculto, ya que otra información de la conexión, como el SNI de TLS cuando no se utiliza ECH, puede revelar el destino.
Espero que os haya gustado, y nos vemos en próximos artículos.