Aunque se ha mencionado de forma incansable en múltiples sitios en internet los mecanismos utilizados por un atacante para “romper” una clave WEP, en contadas ocasiones se intenta explicar en profundidad, que es lo que realmente hacen las herramientas como aircrack-ng, wifislax o wifiway para conseguir su cometido, muchos “hackers” solamente se conforman con romper una clave WEP sin tan siquiera preocuparse por lo que están haciendo sus herramientas por ellos, en esta ocasión se intentará explicar desde un enfoque teórico/técnico como crackear claves cifradas con WEP.
En primera instancia es necesario comprender que el algoritmo RC4 utilizado por WEP para crear un túnel cifrado entre dos instancias inalámbricas (normalmente un cliente y un AP) podría utilizar una clave secreta compartida (Shared Secret Key) de 64 o 128 bits, sin embargo, una de las principales vulnerabilidades de este algoritmo es que utiliza 24 bits que son directamente derivados de los IV (Vector de Inicialización) que se adjuntan a los paquetes que intercambian ambas instancias, estos bits viajan sin ningún tipo de cifrado, es por este motivo que en ocasiones cuando se habla de WEP de 128 bits, sea conocido por WEP de 104 bits y WEP de 64 bits como WEP de 40 bits.
Los tipos de ataque más comunes contra una contraseña secreta compartida son “Pasivos” y “Activos” donde los pasivos, no requieren que el atacante envíe ningún paquete contra el objetivo, solamente se limita a recolectar tantos paquetes como sea posible (y sus correspondientes IV) con el fin de realizar las operaciones de computo y correlación necesarias para descifrar la clave a partir de los IV recolectados. No obstante, este procedimiento puede llevar algún tiempo y se necesitan recolectar una gran cantidad de paquetes con IV validos para intentar obtener la clave, como se puede apreciar, se requiere de paciencia. Por otro lado los ataques activos siguen una filosofía similar en el sentido de que es necesario recolectar tantos IV como sea posible, sin embargo, se acelera el proceso utilizando gracias a los ataques de repetición para que la red se “estimule” y envíe una mayor cantidad de paquetes cifrados con IV validos, en esta categoría también se encuentran los ataques de repetición de peticiones ARP. Además de lo anterior se debe tener presente las siguientes premisas cuando se trata de claves WEP.
-
Para que una clave pueda ser descifrada se deben capturar paquetes que utilicen el mismo IV, de esta forma se puede ejecutar un XOR sobre dichos paquetes y el resultado puede ser utilizado para inferir información sobre los paquetes y descartar posibilidades sobre un espacio de clave para un ataque de fuerza bruta.
-
Los IV débiles no son distribuidos uniformemente, por este motivo es necesario capturar una gran cantidad de paquetes con IV validos y correlacionados.
-
La fortaleza de un IV esta directamente relacionada con la fortaleza de la clave.
Para llevar a cabo un ataque pasivo y/o activo (que en esencia llevan a cabo los mismos pasos) se suele realizar la siguiente secuencia.
-
Capturar paquetes en un fichero de capturas para su posterior análisis (normalmente un fichero pcap será suficiente) para ello, basta con utilizar airodump-ng.
NOTA: Primero se debe de conocer el BSSID y el canal sobre el cual se encuentra trasmitiendo el AP, para ello una ejecución previa de airodump-ng sin ningún filtro podrá determinar todos los AP que se encuentran accesibles y tomar la información de aquel que sea de interés para el ataque.
>airodump-ng –bssid 00:26:4D:88:54:94 –channel 2 –write CrackingWEP mon0
-
Con el comando anterior se almacenarán de forma pasiva los paquetes que viajen desde el AP cuyo BSSID es 00:26:4D:88:54:94 sobre el canal 2 todos estos paquetes se almacenarán en el fichero CrackingWEP. Posteriormente se procede a realizar el ataque de repetición
>aireplay-ng –arpreplay -e WLANXXXX mon0
NOTA: En el caso de que no sea posible obtener peticiones ARP del comando anterior, es posible realizar un ataque autenticación falsa para estimular la red, esto se puede hacer de la siguiente forma
>aireplay-ng –fakeauth 0 -e WLAND54741 mon0
-
Con los pasos anteriores, se deben de generar una cantidad constante de paquetes de datos y peticiones ARP capturadas desde la consola desde donde se ha lanzado el ataque de repetición de peticiones ARP. Una vez se ha capturado una cantidad suficiente de IV (entre 50.000 y 60.000 paquetes de datos aproximadamente) se puede proceder a ejecutar el proceso de “crackeo” de la clave con el fichero de capturas generado anteriormente.
>aircrack-ng CrackingWEP.cap |
Este es el mecanismo más simple y ampliamente difundido, sin embargo se comprende con lo anterior que es lo que realmente ha ocurrido y como es posible que obteniendo paquetes sea posible “crackear” un clave WEP? La respuesta lógica es NO, dado que solamente se ejecutan los comandos de una forma “automatizada” sin un pleno entendimiento de lo que se esta llevando a cabo. A continuación se intentará explicar de forma un poco más profunda las vulnerabilidades de las que se intenta aprovechar herramientas como “aireplay-ng” y muchas otras que se encuentran disponibles en el mercado.
MODIFICACIÓN E INYECCIÓN DE MENSAJES
Se trata de una de las vulnerabilidades más comunes en WEP, consiste en interceptar y modificar paquetes que viajan entre un AP y un cliente (dependiendo del esquema de red empleado) sin necesidad de conocer la contraseña empleada para cifrar el mensaje, este procedimiento permite a un atacante generar paquetes cifrados perfectamente validos a partir de un paquete capturado previamente. El atacante no necesita saber cual es el contenido del paquete capturado, de hecho no lo conoce ya que no cuenta con la correspondiente clave de descifrado, sin embargo puede generar paquetes validos y posteriormente reinyectarlos en la red. El proceso para crear un paquete WEP valido partiendo de un mensaje legitimo es un procedimiento matemático que intentará explicarse a continuación:
-
Un paquete WEP contiene la siguiente información:
-
4 bytes que corresponden al IV del paquete.
-
Un flujo de bytes cifrado que contiene la información que se esta transmitiendo
-
4 bytes que corresponden al ICV (Vector de Inicialización Cifrado) estos bytes son generado por medio del uso de CRC-32 para la detección de cualquier tipo de alteración sobre los datos durante su transmisión.
-
-
Con esta información, un atacante podría intentar crear un “Bit Mask” sin conocer el texto cifrado que se encuentra en el flujo de bytes de un paquete WEP. Para ello crea un flujo de bytes y ejecuta sobre dicho flujo la función CRC-32 con el fin de generar un ICV “parcheado” y de esa forma conformar un paquete WEP valido, el cual puede ser comprobado y aceptado por cualquier AP. De momento la estructura de dicho paquete será la siguiente:
-
Un flujo de bytes (Bit Mask) arbitrario.
-
4 bytes que corresponden al ICV parcheado utilizando la misma función (CRC-32) sobre el Bit Mask.
-
-
Con lo anterior, un atacante tomará el “fragmento” cifrado del paquete WEP original, es decir, el flujo de datos cifrado y el ICV y ejecutará un XOR entre el flujo de datos cifrado del paquete original y el Bit Mask creado por el atacante, así como también realizará un XOR entre ICV original y el ICV creado por el atacante. El resultado de dichas operaciones conforman un paquete WEP perfectamente valido para un AP, cuyo contenido será
-
4 bytes que corresponden al IV del paquete original
-
Un flujo de bytes cifrado con modificaciones resultado de la operación XOR entre el flujo de bytes cifrado y el Bit Mask.
-
4 bytes con el resultado de la operación XOR entre ICV original el ICV parcheado por el atacante.
-
Si se ha comprendido correctamente la explicación anterior (en el caso de que exista alguna duda, deja un comentario en esta publicación) para un atacante es perfectamente posible crear paquetes validos para un AP o un cliente, lo que significa que sin necesidad de conocer la clave WEP con la cual se cifran los paquetes legítimos, un atacante puede inyectar sus propios paquetes y tener un cierto nivel de control sobre la información que viaja entre clientes y AP, esto desde luego abre un amplio abanico de oportunidades a un atacante y es justamente como funciona “aireplay-ng” para redes con un mecanismo de cifrado WEP, ya que internamente lo que intenta hacer es crear paquetes con un “Bit Mask” determinado y producir otro paquete valido partiendo de un paquete legitimo.
Ahora bien, para comprender la razón por la cual es posible generar este tipo de paquetes, es necesario comprender el mecanismo que utiliza WEP para cifrar los datos que se incluyen en un paquete, para ello se describe el siguiente procedimiento
-
En primer lugar, antes de que un cliente envíe un paquete a un AP, los datos se encuentran en texto plano y antes del envío, WEP intenta cifrar dichos datos y para ello utiliza su “KeyStream” es decir, el flujo de bytes que representa la secret shared key y ejecuta una operación XOR entre los datos originales en texto claro y dicho KeyStream, este proceso da como resultado, el texto cifrado. Esto quiere decir, que los campos de un paquete WEP correspondientes al segmento de datos y el segmento de ICV son simplemente el resultado de una operación XOR entre el texto claro y el KeyStream del algoritmo de cifrado, que como el lector recordará, es el RC4 para WEP.
-
Ahora bien, un atacante conociendo esto, puede crear un Bit Mask y un ICV parcheado y utilizar estos campos para realizar un XOR entre el paquete creado “manualmente” por el atacante y el paquete legitimo.
-
Ahora bien, Suponiendo que:
-
OP: Paquete Original en texto plano con su correspondiente ICV
-
MP: Paquete modificado por el atacante con el ICV parcheado
-
KS: RC4 KeyStream.
La operación llevada a cabo por el AP sería la siguiente:
-
OP (xor) KS = Paquete cifrado. |
Gracias a las propiedades matemáticas de las operaciones XOR, se puede inferir lo siguiente:
OP (xor) KS (xor) MP = [OP (xor) MP] (xor) KS |
En realidad, en esta sencilla formula se define la razón por la cual, es posible crear paquetes perfectamente validos ante un AP, dado que, ejecutar una operación XOR entre un Bit Mask/ICV Parcheado y un paquete cifrado/ICV es matemáticamente equivalente a ejecutar la misma operación XOR sobre el paquete en texto plano, en este punto, el resultado final es completamente independiente del KeyStream empleado, el resultado es equivalente en cualquiera de los casos.
Probablemente esta entrada resultará un poco compleja para el lector y tendra que deternerse y releer nuevamente, sin embargo, una vez se han comprendido estos conceptos se entenderá mucho mejor la razón por la cual WEP es tan vulnerable y como funcionan realmente las herramientas que se utilizan para romper una clave WEP. Este es simplemente el paso lógico entre un script kiddie y una persona con conocimientos avanzados.
Hola Adastra,
Lo primero agradecerte tu aportación a este magnífico blog.
Acerca de lo que comentas aquí, sobre la última parte, me surgen un par de dudas, espero que puedas resolvérmelas.
1) ¿El ICV se genera usando el algoritmo CRC-32 sobre la totalidad del paquete o sólo sobre los datos? En caso de que se realice sobre la totalidad del paquete, ¿en el campo del ICV se pondrían todo 0s?
Por ejemplo, en este paquete (es un paquete de Authentication Request), ¿sobre qué campos se calcula el ICV?
2) Acerca de capturar los IVs, tal como yo te entiendo (que seguramente sea mal), los datos se cifran usando la Shared Secret Key, de la cual, 24 de sus bits son parte del IV. Hasta aquí bien, ¿me equivoco? Los IVs son generados de forma aleatoria, pero dado su tamaño (3 bytes) los diferentes posibilidades son 2^24 (16.777.216), por lo que acabarán por repetirse. Una vez tengas al menos 2 iguales, se puede obtener información acerca de la clave.
Lo que sí que no sé, es a qué te refieres con IVs válidos o débiles. Tampoco me queda muy claro si lo que hay que conseguir para descifrar la clave son el mayor número de IVs iguales o con conseguir 16.777.215 IVs también se podría descifrar la clave.
¡Un saludo y gracias por compartir tu conocimiento!
Me gustaMe gusta