Español | English
rss facebook linkedin Twitter

Cómo (no) funciona WEP II

En un post anterior hemos visto cuál es el funcionamiento básico de WEP y cómo los errores en su diseño han tenido como consecuencia la existencia de algunas vulnerabilidades. En este post vamos a seguir explicando más vulnerabilidades.
Además del problema de las colisiones de los vectores de inicialización que pueden usarse para analizar las tramas y deducir partes del flujo RC4, hay otras técnicas más efectivas y eficientes de hacerlo.
Por ejemplo, un punto de acceso puede servir de oráculo en ciertas condiciones. Si desde una dirección IP que está en una LAN cableada podemos enviar datos a uno en una red wifi, el punto de acceso se encargará de cifrar los datos (lógicamente conocidos) para nosotros. De esta manera tenemos los flujos RC4 de los vectores de inicialización que use el AP.


Como ya hemos dicho anteriormente, muchos paquetes contienen cabeceras que son conocidas y que en muchas ocasiones tienen bytes cuyos valores podemos presuponer . De hecho, los 7 primeros bytes de los paquetes de datos son conocidos en prácticamente el 100% de los paquetes y corresponden a la cabecera LLC/SNAP. Por lo tanto asumimos que los primeros 7 bytes son 0xAA, 0xAA, 0x03, 0x00, 0x00, 0x00, 0x08. Haciendo XOR ya tenemos los 7 primeros bytes de un flujo RC4, con los que podemos generar una trama con 3 bytes de datos, ya que hay que incluir 4 bytes del CRC-32. No es mucho, la verdad, pero podemos aprovecharnos de la fragmentación. Efectivamente, podemos enviar, por ejemplo, una petición ARP enviándola de 3 en 3 bytes. El punto de acceso los unirá por nosotros y lo transmitirá. Capturamos esa trama y como ya conocemos el texto en claro (lo hemos generado nosotros), resulta que tenemos un flujo RC4 más largo que el anterior. Si repetimos la operación añadiendo datos sin valor después de la petición ARP, podemos llegar a tener un flujo RC4 de 1500 bytes sin ningún esfuerzo.


Otra vulnerabilidad relacionada con las propiedades de CRC-32 permite descifrar un paquete. Este ataque es conocido como chopchop y fue descubierto por un hacker que se hace llamar KoreK. Si capturamos un paquete cifrado y eliminamos su último byte, el CRC-32 deja de ser válido. Sin embargo, si calculamos cómo cambia este valor, descubrimos que la diferencia entre el original y el modificado solo depende del valor del byte que hemos eliminado. Eso es un dato que desconocemos, pero al fin y al cabo un byte solo puede tener 256 valores diferentes. Podemos presuponer que el valor eliminado era 0. Calculamos el CRC-32 correspondiente, inyectamos el paquete y si el punto de acceso lo retransmite nuestra presunción era correcta. Simplemente probamos todos los valores hasta que encontramos el que es. Hemos descifrado un byte. Repitiendo el proceso recuperamos uno a uno todos los bytes del mensaje original. No solo eso, de paso también tenemos un flujo RC4.

Y por fin llegamos a los ataques más conocidos, los que permiten obtener la clave WEP a partir de tramas cifradas. Era conocido que los primeros bytes de un flujo RC4 estaban sesgados, pero en 2001 Fluhrer, Mantin y Shamir publicaron un paper en el que exponían como ciertos vectores de inicialización son “débiles” y pueden usarse para inferir bytes de la clave secreta usada en el algoritmo RC4. Más en concreto, cuando los 3 bytes del vector de inicialización tiene la forma (3,255,x), donde x es un valor cualquiera, el primer byte del flujo resultante puede puede usarse para calcular el primer byte de la clave WEP. Este cálculo acierta el 5% de las veces aproximadamente, mientras que el 95% restante devuelve un valor aleatorio. Si capturamos 60 tramas con un vector de inicialización de ese tipo, tenemos un 50% de posibilidades de estimar correctamente el primer byte de la clave. Esta probabilidad crece con el número de tramas capturadas. Si el vector de inicialización es (4,255,x) sucede lo mismo con el 2º byte de la clave WEP, lo mismo con (5,255,x) y el tercer byte y así sucesivamente.
Para que este ataque tenga éxito hay que capturar mucho tráfico, hasta reunir el número suficiente de tramas con los vectores débiles necesarios. Aunque esto puede llevar bastante tiempo, el ataque es perfectamente posible y es en lo que se basaban las primeras herramientas que rompían claves WEP.
Más adelante, Klein publicó un trabajo en el que exponía como la correlación entre un flujo RC4 y los primeros bytes de la clave era más fuerte de lo que se pensaba. Para que este ataque tenga éxito, solo es necesario conocer tantos bytes del flujo como la longitud de la clave menos uno. Con esta información es posible hacer estimaciones de los bytes de la clave. Al igual que en el caso anterior, la probabilidad de que esta sea correcta es baja, pero suficiente como para diferenciar el valor entre el resto, que aparecen de una manera mucho más aleatoria. Capturando entre 40000 y 50000 tramas se tiene un 50% de probabilidades de estimar correctamente la clave y con 750000 tramas o más, la probabilidad crece por encima del 90%.
Como ya hemos visto, los primeros 7 bytes de cada trama son conocidos prácticamente en el 100% de los casos. Sin embargo para utilizar la vulnerabilidad descubierta por Klein, necesitamos conocer los 15 primeros. Por suerte, las peticiones ARP tienen el siguiente aspecto:



Los primeros 16 bytes son conocidos, ya que las peticiones se envían a la dirección MAC de broadcast, mientras que las respuesta se dirige a una dirección MAC concreta. Capturando este tipo de tramas podemos obtener los 15 bytes del flujo RC4 que necesitamos inmediatamente. Estas tramas son fácilmente reconocibles porque tienen un tamaño fijo y además son bastante frecuentes (en algunos casos incluso se pueden forzar si es necesario). Además, con las técnicas vistas anteriormente, podemos crear nuestra petición ARP para reinyectarla en la red wifi y hacer que se genere más tráfico con la respuesta, de esta manera se captura el número de tramas necesario en pocos minutos.

En general, las decisiones que se tomaron al crear WEP no son muy acertadas. Especialmente el uso de CRC-32 para comprobar la integridad de los datos, y la forma en que se usa RC4. El análisis de un sistema de cifrado es una tarea ardua que puede durar varios años. Hay que ser muy cuidadoso para evitar llevarse "sorpresas".

Patxi Astiz
S21sec labs


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login