Español | English
rss facebook linkedin Twitter

Cómo (no) funciona WEP I

En este blog hemos hablado varias veces de la seguridad (o falta de ella) en redes inalámbricas. Ésta es la consecuencia de varios errores de diseño en el sistema de cifrado (WEP) que se propuso en el primer estándar 802.11. Seguro que todos vosotros sabéis que la clave de cifrado se puede obtener fácilmente e incluso muchos lo habréis hecho alguna vez (siempre con fines experimentales o educativos). Lo que voy a intentar explicar es qué errores se cometieron al diseñar WEP y como esto ha llevado a hacerlo completamente vulnerable.

En primer lugar, veamos como funciona WEP con una imagen:

En resumen, a los datos a enviar se les aplica un algoritmo para que el otro extremo pueda comprobar si el mensaje ha sido modificado por una tercera persona (Integrity Check Algorithm). En este caso, el algoritmo usado en CRC-32. El texto en claro junto con el resultado de este algoritmo se cifra haciendo un XOR con un flujo RC4 dando el texto cifrado que se enviará. Este flujo lógicamente se genera a partir de una clave que tiene una parte secreta (Shared key) que es la contraseña WEP y otra parte que se conoce como vector de inicialización (los 3 primeros bytes), cuyo objetivo es evitar que se repitan la claves y que se añade sin cifrar a las cabeceras de la trama a transmitir. Cuando el otro extremo recibe el paquete, lee el vector de inicialización que junto con la clave secreta le permite obtener exactamente el mismo flujo RC4. Se descifra el paquete, se calcula el CRC-32 de los datos y se compara con el que incluye el paquete.

Aunque RC4 es en principio secreto, un anónimo envió a una lista de correos de criptografía los detalles del algoritmo. A día de hoy dicho algoritmo se conoce como ARC4 y hasta ahora no se ha detectado ninguna diferencia en su comportamiento respecto al RC4 original. La idea se resume (mucho) en esta imagen:

Todo esto tiene varios problemas. Igual algunos de vosotros os habéis dado cuenta de que CRC32 es lineal respecto a la operación XOR. Esto significa que podemos modificar un bit de una trama cifrada que hayamos capturado y enviarla. En principio el receptor, tras descifrar el mensaje vería que el bit ha cambiado, y también que el CRC32 no coincide. La solución es muy fácil. En esta imagen vamos a invertir tan solo el bit marcado con un 1:

Efectivamente, si calculamos el CRC-32 de los cambios, tenemos los bits del CRC-32 original que hay que cambiar para que la trama sea válida.

Pero hay más decisiones incorrectas. Por ejemplo, el vector de inicialización sirve para no utilizar siempre la misma clave en el algoritmo RC4. Si no se hiciera así, sería fácil adivinar el flujo RC4 con el que se cifra tras observar unos cuantos paquetes. Cambiando el vector de inicialización para cada trama, ese flujo es diferente cada vez. Sin embargo, el estándar no dice nada acerca de cómo debería cambiar. De hecho, ni siquiera obliga a que realmente cambie. Es opcional. Incluso en el mejor de los casos, la longitud es de solo 24 bits (más de 16 millones de valores posibles), por lo que si por ejemplo elegimos el vector al azar, con menos de 5000 paquetes, la posibilidad de que un vector de inicialización se repita llega al 50% (la paradoja del cumpleaños). Acumulando varios paquetes con vectores repetidos, lo más seguro es que estos tengan peticiones de ARP, paquetes ICMP o cabeceras IP y TCP que tienen una estructura conocida y muy regular. Con varios paquetes es estadísticamente muy posible que lleguemos a deducir el contenido (o una parte importante) de estos paquetes y el flujo RC4 que se ha usado para cifrarlos. Por ejemplo, los paquetes ARP son especialmente sencillos de reconocer ya que tienen un tamaño fijo y una estructura que prácticamente no cambia de uno a otro.

Así que de momento podemos llegar a ver partes de los mensajes y saber algunos fragmentos del flujo de cifrado. Esto es muchísimo más de lo que deberíamos saber si el sistema de cifrado fuera bueno. Ahora podemos generar un paquete, cifrarlo con la parte del flujo RC4 que hemos obtenido y enviarlo con el vector de inicialización correspondiente. El resultado es una trama correctamente cifrada, sin conocer la clave, que podemos emitir y los usuarios legítimos entenderán y aceptarán como válida.

Esto es el principio. Como ya sabéis, el sistema WEP tiene muchas vulnerabilidades aún más graves que nos permiten descifrar tramas que hemos capturado, calcular flujos RC4 de hasta 1500 bytes o lo más grave, obtener la clave de cifrado usada, pero sobre eso hablaremos en el próximo post.

Patxi Astiz
S21sec labs


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login