TCP Iddle Scans en IPv6 usando Fragmentation Headers

Cuando estuve actualizando todo el capítulo dedicado a ataques en IPv6 del libro de Ataques en redes de datos IPv4/IPv6 me paré a ver algunas herramientas y artículos que habían sido publicados sobre IPv6 para que pudieran estar todas referenciadas en él. No quería dejarme mucho sin incluir en ese capítulo. Entre las cosas que se añadieron estuvieron la nueva versión de Topera2 que no solo incluía el escaneo de puertos TCP sino que también añadió el soporte del ataque slowloris, las nuevas herramientas de Fernando Gont, y el artículo de Mathias Morbitzer dedicado a los TCP Iddle Scans  en IPv6 que se publicó en la Hack in The Box Magazine #10.

La idea de hacer un iddle scans tiene que ver con el anonimato a la hora de escanear un servidor utilizando una máquina zombie para enviar la mayoría de los paquetes que son necesarios para saber qué puertos tiene abiertos un servidor objetivo. En IPv4 esto se ha hecho y se conoce desde hace mucho tiempo, pero en IPv6 era necesario actualizar el método ya que los cambios en las cabeceras eliminan el campo IPID que se utilizaba para identificar si un mensaje RST había sido enviado desde el servidor objetivo o no, lo que significaba que el puerto estaba abierto.

En IPv6 se ha modificado totalmente el proceso, pero sigue siendo posible hacer uso de este tipo de escaneos siguiendo el esquema descrito por Mathias Morbitzer que se recoge en este gráfico.

Figura 1: Esquema de un TCP Iddle Scan en IPv6

Los pasos son más, pero se consigue el mismo objetivo haciendo uso de las cabeceras de fragmentación [Fragmentation Headers FH()] y jugando con el Path MTU, el MTU y el Minimum MTU en IPv6, para conseguir la fragmentación e identificación de los paquetes fragmentados, lo que permitirá contar un nuevo ID cuando se haya producido la fragmentación que se incrementa en cada paquete enviado por el servidor con FH, incluido los RST. El esquema es:

1.- Se envia un Eco Request con la IPv6 de origen spoofeada con la del servidor que se quiere escanear. El paquete debe llevar datos suficientes como para estar fragmentado. 

2.- El iddle host enviará el Echo Response al equipo objetivo, con la fragmentación activada. 

3.- A ciegas, el atacante enviará un mensaje de Packet Too Big (PTB) especificando un Path Maximum Tram Unit cercana al IPv6 Minimum MTU. 

4.- El atacante enviar ahora un Echo Request con su dirección IP real y con la fragmentación activada. 

5.- El iddle host contestará al atacante con la fragmentación activada, lo que le permite al atacante saber si está utilizando la identificación de fragmentación. No todos los equipos tienen la misma implementación, y puede ser que la identificación de paquetes fragmentados sea por host, lo que no dejaría la opción de contar los incrementos. En la tabla de la figura 2 se da una lista de los resultados al utilizar diferentes hosts como iddle host. 

6.- El atacante enviará un mensaje PTB con su dirección IP real y especificará un MTU más pequeño de 1280 bytes, lo que hará que el iddle host añada una FH a todos los paquetes IPv6 que genere. A partir de ese momento el ataque será similar al de IPv4 y consistirá en contar los incrementos en la identificación de los fragmentos.

Figura 2: Resultados con los distintos tipos de hosts usados como iddle host

Con el proceso anterior lo único que se ha conseguido es configurar la fragmentación de paquetes en el iddle scan para poder contar los ID de los fragmentos, para lo que se hará:

7.- Se envía un SYN con la dirección de origen spoofeada con el iddle host al puerto que se quiere probar del servidor objetivo. 

8.- El objetivo devolverá un RST si está cerrado (8a) o un SYN+ACK (8b) si está abierto.
9.- El iddle host, si recibe un SYN+ACK contestará con un RST utilizando un ID+1 para identificar el nuevo fragmento. 

10.- Para saber el resultado final de si el puerto está abierto o no, el atacante enviará un SYN+ACK al mismo puerto pero del iddle host con la dirección IP real del atacante. 

11.- Se recibirá un RST en cualquier caso al no existir un SYN, pero si el ID ha incrementado solo en 1, eso significa que el puerto del objetivo está cerrado, pero si el incremento es en 2, entonces el puerto estaba abierto.

Este escaneo permite a los auditores en redes IPv6 utilizar un mecanismo que en IPv4 esta bien extendido. En el artículo se añade un script para hacer la prueba con Scapy y cómo utilizarlo ya en nmap, así que si quieres probarlo, merece la pena que te leas el artículo original en la página 4 de la revista.

Saludos Malingos!