Wireshark Network Analyzer Parte II

Ataques en Redes de Área Local.

1.- ARP Spoof

Ademas de servirnos como método de captura en ciertos escenarios, el ARP Spoof es comunmente utilizado por atacantes para interponerse entre una o varias máquinas con el fin de interceptar, modificar o capturar paquetes. Esta técnica, es considerada bastante intrusiva, pero gracias a Wireshark podemos observar lo sospechoso trafico ARP que se esta reciendo, y si observamos mas detalladamente el comportameinto del protocolo, nos daremos cuenta de que el servidor esta siendo víctima de un ataque.

En el paquete número 5 podemos ver cómo la máquina con IP 10.0.0.101, con una MAC IntelCor_6e:a2:69, ha lanzado un ARP request a la dirección broadcast preguntando por la MAC de la IP 10.0.0.1 (el gateway de nuestra red). Acto seguido, el router contesta con un ARP reply indicando cuál es su dirección MAC. A continuación, la misma IP repite el proceso y pregunta por la MAC de la IP 10.0.0.100 (servidor de ficheros) mediante otra difusión broadcast. El servidor contesta con su dirección MAC (IntelCor_49: bd:93). Hasta aquí todo normal. Tenemos una máquina de nuestra LAN (10.0.0.101), que ya tiene la MAC del servidor y la del router con las cuales ya puede compartir tráfico Ethernet. El problema viene a partir del paquete 11, donde la máquina anterior envía reiteradamente a nuestro server y al router paquetes ARP reply falsos, asociando la IP de ambos con su propia MAC (IntelCor_6e:a2:69). De esta forma, todo el tráfico que transite entre el gateway de la LAN y el server pasará a través de la máquina atacante. Herramientas como Ettercap, Cain y Abel o la suit Dsniff permiten llevar a cabo este tipo de ataques sin necesidad de conocer en profundidad el funcionamiento de Ethernet o el protocolo ARP lo que incrementa su peligrosidad ya que un atacante no necesitaría tener conocimientos muy avanzados para capturar conversaciones de protocolos que viajen en claro, obtener contraseñas, ficheros, redirigir tráfico, etc.

Gracias a la información que nos proporciona Wireshark, puede resultarnos útil en determinados escenarios (pentesting, auditorías, etc.) generar tramas o paquetes para enviarlos por una interfaz. Actualmente existen excelentes herramientas para tal propósito como Scapy, que nos permite crear todo tipo de paquetes desde cero. Sin embargo,  no resultaría  complejo  hacer  lo mismo  a  partir  de  tráfico capturado  en Wireshark.

Siguiendo el ejemplo anterior, podríamos capturar un  paquete ARP válido, modificarlo y enviarlo posteriormente por una interfaz con el objetivo de envenenar la caché ARP de una máquina determinada.

A continuación, se muestra el formato en bruto de una respuesta ARP generada por nuestro equipo a un ARP request. Podemos buscar estos paquetes con el siguiente filtro arp.opcode == 0x0002 (ARP reply):

Como se comentó anteriormente, el texto hexadecimal mostrado en la zona inferior se corresponde con la trama tal y como se trasmite por la red. Por tanto, nada nos impide tomar eso valores, modificarlos y reenviarlos de nuevo. Para ello, pulsamos el botón derecho del ratón sobre el “Frame 46” y seleccionamos “Export Selected Packet Bytes” y guardamos la trama en un fichero.

Posteriormente, con cualquier editor Hexadecimal, modificaremos la trama creando un ARP reply. En nuestro caso queremos enviar un ARP reply modificado a la máquina 192.168.254.245 con MAC 00:15:58:e8:50:0e haciéndonos pasar por el gateway (IP 192.168.254.254 con MAC 00:0e:0c:c6:c5:82):

Tras modificar la trama podemos enviarla directamente por la interfaz conectada a nuestra LAN mediante la aplicación file2cable:

root@bt:~# file2cable -i eth0 -f arpreply

Para comprobar si ha surtido efecto, podemos comprobar la caché ARP de la víctima: Posteriormente, con cualquier editor Hexadecimal, modificaremos la trama creando un ARP reply. En nuestro caso queremos enviar un ARP reply modificado a la máquina 192.168.254.245 con MAC 00:15:58:e8:50:0e haciéndonos pasar por el gateway (IP 192.168.254.254 con MAC 00:0e:0c:c6:c5:82):

Podemos mantener el ataque, por ejemplo, mediante un script que ejecutará la instrucción en un bucle. Así conseguiríamos contaminar de forma constante la caché de la víctima dando como resultado que ésta envíe todos los paquetes dirigidos fuera de la LAN a nuestro equipo atacante. Lógicamente, para que este ataque tenga éxito, habría que realizar la misma operación con la caché del Gateway o del equipo víctima para conseguir un MitM (Man in the Middle) al completo.

2.-  Fort Flooding 

Un  ejemplo  similar  al  anterior,  aunque  más  fácil  de  detectar,  consiste  en  enviar múltiples tramas falsificadas a través de un puerto con el objetivo de llenar la tabla de asignación del switch. Generalmente un switch dispone de una memoria interna denominada CAM (Content-Addressable Memory) donde asigna puertos a direcciones MAC. Cuando una trama llega a un puerto, la CAM añade una entrada a la tabla especificando la MAC del equipo que envió la trama junto con el puerto en el que se encuentra. De esta forma, cuando el switch recibe una trama dirigida a ese equipo sabrá por qué puerto debe enviarla.

En caso de desconocer el destino de la trama, bien porque el equipo no ha llegado a generar tráfico o bien porque la entrada asociada a ese equipo ha expirado, el switch copiará la trama y la enviará por todoslos puertos de la misma VLAN excepto por aquel por el que fue recibida. De esta forma, todos los equipos conectados al switch recibirán  dicha  trama  y  únicamente  el  equipo  correspondiente,  aquel  cuya  MAC coincida con la MAC destino de la trama, contestará; lo que permitirá al switch añadir una entrada a su tabla CAM con la nueva asociación MAC/puerto. Gracias a esto, el switch no necesitará inundar (flood) todos los puertos con futuros paquetes dirigidos a ese equipo.

Pero, ¿qué pasaría si se envían cientos de tramas falsificando la MAC origen del equipo y llenando la tabla CAM?... En ese caso, su comportamiento depende del fabricante. Los switches de baja gama no contienen tablas CAM virtualizadas, es decir, que si la tabla dispone de un número n máximo de entradas para almacenar las asociaciones MAC/puerto, y un equipo consigue llenar dicha tabla con n entradas, la tabla se llenará y todas las VLANs se verán afectadas. 

Con tablas CAM virtualizadas se mantendría un espacio de direcciones independiente para cada VLAN. De esta forma, sólo se verían afectados los equipos de la propia VLAN.

Yersinia o Macof permiten generar una inundación (flooding) de paquetes con MAC creadas aleatoriamente con el fin de saturar la tabla de asignaciones del switch:

3 .- Ataques DDoS 

La Figura a continuacion representa un ejemplo de ataque de denegación de servicio (DoS) a pequeña escala, llevado a cabo por hping2 y que también salta a la vista nada más comenzar la captura. En este caso tenemos un Apache instalado en la máquina 10.0.0.101 y observamos gran cantidad de segmentos TCP con el flag SYN activados desde la misma IP, que no reciben respuesta alguna por parte del servidor web.

Podemos ver, de forma gráfica, la secuencia de paquetes pinchando en el menú Statistics >> Flow Graph. Esta herramienta nos facilitará en numerosas ocasiones seguir el comportamiento de conexiones TCP, ya que, como vemos en la imagen, describe de forma muy intuitiva mediante flechas, el origen y destino de cada paquete, resaltando los flag activos que intervienen en cada sentido de la conexión.

En nuestro caso se observa que, en un intervalo muy corto de tiempo, existen numerosos intentos de conexión por parte de la IP 10.0.0.200 al puerto 80 de la máquina 10.0.0.101, situación algo inusual. El servidor ha tratado de resolver la MAC de la máquina cliente en numerosas ocasiones, una de ellas la podemos ver en el paquete 7852, pero, al no recibir respuesta alguna y, por tanto, al carecer de la dirección física del host, no puede enviar un ACK-SYN al mismo para continuar con el establecimiento de la conexión a tres pasos.

Esto conlleva que la pila TCP/IP de nuestro servidor tenga que esperar por cada conexión un tiempo determinado, durante el cual seguirán llegando más paquetes que irán creando nuevas conexiones. Por cada conexión que se intente establecer se creará una estructura en memoria denominada TCB (Transmission Control Block) que es usada por la pila TCP/IP del sistema operativo para identificar cada una de las conexiones (sockets local y remoto, segmento actual, punteros a buffers de envío y recepción, etc) y que, con un número muy elevado, pueden acabar con los recursos de la máquina produciendo que el equipo deje de contestar más solicitudes de conexión.

Similar a este tipo de ataques fue el llevado a cabo  recientemente por el grupo Anonymous de 4chan contra los servidores de Amazon y Paypal mediante las herramientas LOIC (Low Orbit Ion Cannon) y HOIC (High Orbit Ion Cannon) debido a los  altercados  con  Wikileaks.  Estas  herramientas  constan  de  una  interfaz  muy amigable desde la cual se puede elegir entre diversas opciones de ataque como son peticiones UDP, TCP o HTTP así como la velocidad y la cantidad de threads simultáneos.

4 .- DHCP Spoof  

Otro tipo de ataque menos común, pero igual de eficiente que el ARP Spoof, consiste en falsificar paquetes DHCP. El ataque consiste en instalar un DHCP falso  o un software que emule las funciones del mismo de tal forma que responda a peticiones DHCPDISCOVER de los clientes. Es necesario analizar los pasos llevados a cabo entre un cliente y un servidor DHCP legítimo para comprender el ataque en mayor profundidad:

• Cuando un equipo se conecta a la red y solicita una dirección IP envía un DHCPDISCOVER a la dirección broadcast (UDP) esperando respuesta por algún servidor DHCP.

• Éste contestará a tal petición enviando un paquete unicast denominado DHCPOFFER y que contiene varios parámetros de configuración (IP, gateway, etc.).

• Hasta este punto, el cliente puede recibir ofertas de varios servidores DHCP por lo que utilizará el siguiente criterio de elección: si la oferta propuesta se corresponde con una dirección previamente asignada (ya que son recordadas por el cliente), el cliente seleccionará ésta. En caso de que la propuesta no esté relacionada con una dirección IP previa, el cliente adquirirá la primera oferta recibida.

• En respuesta a esta oferta, el cliente enviará un DHCPREQUEST a la dirección broadcast  pidiendo autorización para utilizar  esa configuración  a  lo  que  el servidor responderá, o bien con un paquete unicast DHCPACK autorizando el uso de dicha configuración, o bien con un DHCPNAK denegando el uso de tales parámetros.

La parte interesante es que el protocolo DHCP no proporciona mecanismos de autenticación que permitan verificar el origen de los paquetes durante la negociación de estos parámetros de configuración. Por lo tanto, nada impide que un atacante pueda falsificar paquetes DHCPOFFER proporcionando información falsa al cliente.

Un posible escenario de ataque consistiría en proporcionar, como puerta de enlace, la propia IP del atacante con el fin de recibir paquetes destinados hacia fuera de la LAN. El atacante enrutaría estos paquetes hacia el sitio legítimo con el objetivo de hacer el ataque totalmente transparente al usuario.

De la misma forma, el atacante podría falsificar respuestas DNS especificando su IP como servidor DNS para poder manipular cualquier resolución de nombres posterior.

Si nos encontramos en una situación de este tipo, Wireshark mostraría un uso anormal del protocolo DHCP. Otro síntoma podría ser la generación de errores en nuestras máquinas debido a IPs duplicadas.

Herramientas como Yersinia, Ettercap o simplemente configurando un servidor DHCP en el equipo del atacante, como dhcpd3, son suficientes para hacer un MitM (Man in the Middle) usando respuestas

falsificadas DHCP.

Veamos un ejemplo. Un atacante configura un servidor dhcpd3 en su equipo Linux con los parámetros mostrados en la figura anterior (/etc/dhcp3/dhcpd.conf)

En él se configura un rango de 4 direcciones IP en desuso (que puede obtener entre aquellas que no tengan un registro DNS PTR, que no estén escuchando por servicios comunes o simplemente escuchando respuestas legítimas del servidor DHCP) y un default gateway legítimo (192.168.254.255), pero especifica como servidor DNS la IP del atacante (192.168.254.211). Además, prepara Ettercap para falsificar ciertas respuestas DNS :

       

                       echo www.inteco.es A 192.168.254.211 >> /usr/share/ettercap/etter.dns

Cuando un usuario se conecta a la red y solicita una IP por DHCP, nuestro servidor falso le facilitará todos los datos necesarios y, como servidor DNS, la IP del atacante:

A  partir  de  ahora  el  atacante  podrá  manipular  las  respuestas  DNS  de  forma transparente al usuario:

Un método más ofensivo, publicado en hackyeah, consiste en utilizar filtros Ettercap para manipular peticiones HTTP.

El ataque se aprovecharía de un DNS o un ARP Spoof como los vistos anteriormente, y consistiría en insertar un iframe oculto en cada petición que contenga una etiqueta ; este iframe apuntaría a la dirección del atacante mientras ejecuta el módulo browser_autopwn de Metasploit. A continuación se muestra un extracto de código, proporcionado por hackyeah  22, para crear un filtro  que inyecte un iframe en las respuestas HTTP:

Tras compilar el filtro y lanzar Ettercap, cada vez que la víctima haga una petición HTTP, Ettercap   reemplazará   en   las   respuestas   del   server   "   por