Un nuevo ataque a WPA/TKIP

Desde que a primeros de noviembre de 2008, Erik Tews y Martin Beck abrieran la caja de Pandora demostrando la viabilidad de capturar información enviada desde un router protegido con WPA/TKIP, se han ido sucediendo pequeños avances en las técnicas utilizadas en dichos ataques yendo desde la inyección de un mayor número de paquetes maliciosos (tal y como se demostró en un paper publicado por unos estudiantes de la universidad de ciencia y tecnología de Noruega en la NorSec Conference celebrada a mediados de octubre de 2009) hasta el último ataque conocido en el que, Matin Beck, vuelve a la carga con un nuevo ataque (PDF) que, gracias a un refinamiento de la técnica utilizada, permite inyectar no solamente un mayor número de paquetes, sino que estos, pueden contener más información.

Haciendo memoria

Recordemos que, TKIP (Temporary Key Integrity Protocol), es una variante de WEP. El hecho de que inicialmente WPA utilizara este sistema -frente al más seguro AES- se debe, simplemente, a una cuestión económica.

En la mayoría de los casos, un router que soportase el protocolo WEP podría ser actualizado por software para soportar el protocolo WPA/TKIP pero, probablemente no a WPA/AES pues, este último, es computacionalmente más exigente que el primero y, por tanto, sería necesario una actualización del hardware -normalmente mediante un cambio de router- con el coste que ello implicaría.

De todas formas, TKIP si que supone un pequeño avance frente a WEP pues, aparte del vector de inicialización del paquete presente en el protocolo WEP (los conocidos como IVs), se utiliza una clave de sesión que, convenientemente "mezclada" con el vector mencionado anteriormente, impide utilizar los ataques conocidos en la actualidad para WEP ya que cada uno de los bytes de un paquete, depende tanto del vector de inicialización como de la clave de sesión. Además de esto -y para evitar ataques basados en la fragilidad de la protección por CRC32 utilizado en WEP-, TKIP implementa dos medidas adicionales: un Message Integrity Check (MIC) de 64 bits incluido en cada paquete a transmitir conocido como "MICHAEL", y un contador de secuencia (TSC) diseñado para asegurar el orden de recepción de los paquetes.

La propuesta inicial de Erik y Martin se basaba en utilizar una variante del ataque Chopchop que describimos en su forma original (orientado al ataque de redes cifradas con WEP) a continuación:

El ataque Chopchop original

Este procedimiento permite a un atacante descifrar los últimos n bytes de información de un paquete mediante el envío de una media de n * 128 paquetes al punto de acceso. La idea se basa en lo siguiente:

En redes protegidas con el protocolo WEP, antes de ser cifrados, los paquetes son modificados de tal forma que se añade un CRC32 conocido como ICV al final del contenido del paquete. A pesar del cifrado posterior, es posible averiguar el valor del último byte de datos del paquete eliminando dicho byte del paquete (truncando el paquete) utilizando una característica presente en la mayoría de los puntos de acceso: si reciben un paquete correcto de un cliente no autenticado, el punto de acceso genera un error, pero, si reciben un paquete con un checksum incorrecto, ese paquete es, sencillamente, descartado. Dado que se ha eliminado un byte basta con mandar a lo sumo 256 paquetes (de media, 128) para averiguar el valor del byte elminado. Una vez conocido el valor del último byte de datos se puede realizar la misma operación con bytes precedentes tantas veces como bytes queramos descifrar.

Contramedidas implementadas en WPA/TKIP

Como se ha comentado anteriormente, TKIP implementa dos contramedidas para evitar ataques como el descrito arriba:

* Si se recibe un paquete con un ICV erroneo, se asume que se ha producido un error en la transmisión y el paquete es descartado. Si, por contra, el ICV es correcto -pero la verificación del MIC fallase-, se consideraría que se está produciendo un ataque y, el punto de acceso, respondería enviando un MIC failure report frame. Si se producen más de dos errores en la validación del MIC en un intervalo de menos de 60 segundos se corta la comunicación y se renegocian todas las claves tras un periodo de penalización de 60 segundos.

* Si un paquete es recibido correctamente -su ICV y su MIC son correctos- se actualizará el contador TSC incrementándose en una unidad. En caso de que el TSC fuese inferior al valor del contador (el paquete habría sido recibido en un orden incorrecto), este sería descartado sin mayores consecuencias.

A pesar de todas estas contramedidas el uso del ataque Chopchop sique siendo viable con TKIP simpre y cuando se haga teniendo cuidado de no "disparar las alarmas".

La cuestión es ¿qué ganamos consiguiendo averiguar los últimos bytes de un paquete cifrado?. En principio podría parecer que la información obtenida es tan pequeña que no tiene ninguna utilidad práctica, sin embargo, pronto veremos que esto no es así.

Atacando WPA

Para empezar, es necesario que el router en el que se ejecute el ataque tenga habilitado QoS de forma que existan varios canales (según la especificación, ocho) por los que transmitir pues, dado que cada canal tiene un contador distinto para el TSC -y el tráfico normalmente siempre circula por el canal 0-, es posible inyectar paquetes con TSCs "bajos" por los siete canales normalmente inactivos sin "levantar sospechas". Es posible por tanto enviar paquetes modificados a aquellos canales con un contador TSC bajo teniendo cuidado, eso si, de no enviar más de dos paquetes con un MIC incorrecto en el intervalo de un minuto.

Supongamos que nos enfrentamos con una red Wi-Fi protegida con WPA/TKIP y que utiliza IPv4 y de la que conocemos el rango de direcciones utilizado (p. ej. 192.168.1.0/24). Adicionalmente, y como hemos visto anteriormente, el router deberá tener activado el QoS y el periodo de regeneración de las claves de la red deberá ser alto (p. ej. 3600 segundos).

Dado este escenario (bastante realista para muchas de las redes desplegadas actualmente), para atacar dicha red sería necesario capturar tráfico hasta detectar un paquete ARP (facilmente distinguible del resto en base a su longitud característica).

Haciendo un inciso -y aunque no es importante para explicar el ataque- es interesante señalar que, en una red Wi-Fi, aunque la comunicación esté cifrada, las direciones MAC tanto origen como destino aparecen en claro y los paquetes son enviados siempre a la dirección de broadcast de la red.

En un escenario como el descrito, se conoce la práctica totalidad del contenido de un paquete ARP, quedando por averiguar el último byte de las direcciónes IP origen y destino, los 8 bytes del MIC y los 4 del checksum ICV. El MIC y el ICV conforman, por tanto, los últimos 12 bytes del paquete.

Teniendo en cuenta que no podemos mandar más de dos paquetes con un MIC incorrecto en el intervalo de un minuto -aunque si que podemos mandar tantos paquetes con un ICV incorrecto como queramos hasta "acertar" pues, siendo incorrectos, serán descartados sin más (sin alterar el valor del TSC del canal) necesitaremos alrededor de 12 minutos para averiguar los 12 bytes que conforman el MIC y el ICV y un par más si queremos averiguar también las direcciones origen y destino del paquete.

Una vez recuperado el MIC y el ICV de un paquete, el atacante puede recuperar la clave utilizada para generar el MIC de dicho paquete -el algoritmo MICHAEL no fue diseñado para ser una función de un solo sentido y es igual de eficiente ejecutarlo "hacia atrás" que "hacia delante"- y, desde ese momento, hasta la resincronización de claves, pueden generarse paquetes "firmados" con la clave MIC obtenida y cuyos 4 bytes ICV correctos podrán averiguarse mediante un ataque Chopchop.

En esta forma, el ataque únicamente permite el envío de tráfico que pueda hacer saltar IDSs que trabajen a nivel de IP o, si el usuario está conectado a Internet, se podría provocar la fuga de información rutando tráfico hacia una máquina externa mediante respuestas ARP falsas.

Por último, a pesar de que con este ataque no es posible descifrar los paquetes de respuesta del cliente transmitidos via Wi-Fi, sería posible obtener dichos paquetes a través de la conexión a Internet mediante la técnica de ARP spoofing descrita anteriormente.

Mejoras introducidas en el nuevo ataque

Una vez aclarado el funcionamiento del ataque original a WPA veremos las novedades aportadas por el nuevo ataque.

La principal mejora es el aumento significativo de información que es posible inyectar en la red pues, con el ataque anterior, en la práctica solamente era posible enviar 28 bytes de información por cada paquete descifrado.

La idea en la que se basa esta mejora es la de la fragmentación de paquetes. La especificación 802.11 permite fragmentar un paquete hasta en 16 partes, sin embargo, TKIP impide reutilizar el keystream de un vector de inicialización dado en más de un fragmento, por lo que es necesario disponer de al menos 16 keystreams distintos para poder transmitir estos. Dado que el ataque explicado anteriormente precisa de 15 minutos para obtener un paquete ARP completo no sería viable utilizar dicho método para llevar a la práctica nuestra idea.

Con el fin de conseguir nuevos keystreams debemos forzar la generación de nuevos paquetes en la red de los cuales conozcamos la mayor cantidad de información. Los paquetes perfectos para esto son los TCP-SYN que, enviados mediante IP spoofing -haciéndonos pasar por el punto de acceso- a un puerto TCP abierto en el cliente, provocarán la respuesta TCP-SYN/ACK a la que el propio punto de acceso, responderá con un paquete TCP-RST generando un nuevo IV dirigido hacia el cliente y que podremos capturar.

Para llevar a cabo esta idea debemos ser capaces de generar un paquete TCP/IP que consistirá en: 8 bytes de cabecera LLC, 20 bytes de cabecera IP y otros 20 de cabecera TCP lo cual nos da 48 bytes de longitud para la MSDU y, a esto, hay que añadirle los 8 bytes del MIC que hacen en total 56 bytes. Asumiendo que disponemos de 8 bytes de keystream para cifrar información, utilizando los siete canales restantes (proporcionados por el QoS del punto de acceso) seremos capaces de cifrar 7 x 8 = 56 bytes por lo que, dado que el envió de un TCP-SYN genera un único TCP-RST, con este método nunca podríamos obtener nuevos bytes de keystream "utilizables".

Necesitamos, por tanto, encontrar una forma de conseguir un mayor número de bytes de keystream que nos permitan inyectar tráfico extra en la red.

Casualmente, muchos sistemas Linux -como los que usan una gran cantidad de routers ADSL- generan paquetes TCP-RST con valores concretos en ciertos campos que nos permitirían obtener un mayor número de bytes de keystream a partir de los paquetes TCP-RST capturados.

Por ejemplo, el ID de dichos paquetes suele ser 0 -por lo que se obtendrían dos bytes extra- de los dos siguientes campos, el byte en el que se indica la fragmentación sería también cero -al no haber más fragmentos- y el de los flags sería, o bien cero, o 0x40 para indicar que no se debe fragmentar el paquete; el siguiente byte -el TTL- probablemente será 0x40 pues es el valor utilizado por defecto en Linux; así mismo, el byte para indicar el protocolo será 0x06 indicando que se usa TCP, las IPs de origen y destino y los puertos TCP serán conocidos así como el número de secuencia que será igual al original incrementado en uno, ...

Siguiendo de forma similar con el resto de los campos del paquete podríamos llegar a obtener hasta 60 bytes de keystream por cada uno de los siete canales libres sin necesidad de fragmentación.

Suponiendo que podamos conseguir todos los requisitos expuestos anteriormente, seríamos capaces de generar 60 nuevos bytes de keystream a la velocidad de la conexión wireless. Incluso, en caso de que el punto de acceso no cumpliese con estos requisitos, si la red a atacar tuviese conexión a Internet y no estuviese filtrado el establecimiento de conexiónes hacia máquinas de Internet, sería viable hacer spoofing de una IP de un sistema externo en el cual tuviésemos control de los paquetes TCP-RST generados lo cual permitiría generar nuevos bytes de keystream aunque, eso sí, la velocidad de generación quedaría limitada a la velocidad de descarga de dicha conexión.

Conclusiones

En resumen, y como se ha comentado inicialmente, este ataque permitiría extraer mucha más información de una red protegida con WPA/TKIP consituyendo un serio problema de seguridad en cuanto a la fuga de datos que ello supone.

Aunque en la práctica este ataque es complejo dado que se necesita la confluencia de un gran número de factores -la red debe estar cifrada con WPA/TKIP que poco a poco va cayendo en desuso, el atacante debe estar a una distancia que le permita inyectar paquetes y el punto de acceso debe tener activado QoS y estar basado en Linux- La forma de evitar este problema es tan simple como utilizar WPA/AES a la hora de configurar una red Wi-Fi.

Dejamos para una futura entrada el analizar el otro avance presentado que, en resumen, es un ataque al código de integridad del mensaje (MICHAEL) que permitiría insertar información en un paquete con datos y MIC desconocidos consiguendo con ello el objetivo de poder descifrar todo el tráfico dirigido hacia el cliente.

Fernando Braquehais

S21sec. e-crime

http://blog.s21sec.com/2010/03/un-nu...Blog+S21sec%29