Korek ChopChop

Para comprender correctamente como es el funcionamiento de este ataque, es necesario partir de lo que se ha explicado anteriormente en la parte VII de esta serie de publicaciones en donde se ha indicado uno de los principales “puntos débiles” de WEP, que es precisamente la forma mediante la cual se cifran los paquetes y las facilidades con las que cuenta un atacante para generar un paquete WEP cifrado perfectamente valido para el AP aunque no se disponga de la clave. Se trata de una “vulnerabilidad” intrínseca en funcionamiento de WEP y es uno de los tantos motivos por los cuales ha surgido WPA y WPA2 (de las que se hablará más adelante). Como se recordará, una aplicación practica de esta vulnerabilidad es el ataque Caffe Latte, en donde la finalidad es la generación de paquetes ARP (paquetes ARP cifrados sin la necesidad de conocer la clave WEP) que pueden ser enviados al cliente de forma automática y constante para posteriormente recolectar suficientes IV (Vectores de inicialización) que serán útiles para conseguir crackear la clave.

En el caso del ataque “Chopchop” se sigue un mecanismo bastante similar, partiendo de la premisa de “capturar” un paquete cifrado con la clave WEP compartida y ejecutar el ataque. Los pasos involucrados para llevarlo a cabo, así como la “filosofía” empleada es la siguiente:

  1. Partiendo de un paquete capturado (cifrado con una clave WEP) el atacante no conoce la clave que le permita descifrar dicho paquete, sin embargo puede utilizar la técnica de modificación e inyección de paquetes (como se ha explicado anteriormente), pero antes de hacerlo, procede a determinar cual es el ultimo byte del paquete cifrado, (dentro de la zona de datos cifrados del paquete, sin tener en cuenta el fragmento del paquete correspondiente al ICV cifrado)

  2. Una vez que el atacante ha localizado la posición del ultimo byte de los datos cifrados, se procede a removerlo y a generar un nuevo paquete (utilizando la técnica de modificación de paquetes explicada en la publicación anterior sobre cracking WEP) cuyo tamaño será más pequeño que el tamaño del paquete legitimo capturado

  3. Ahora viene la parte interesante de este ataque, cual es la finalidad de tener un paquete cifrado legitimo (sin conocer la clave WEP) y un paquete con la misma información pero con un byte más corto en la zona de datos cifrados? Como se recordará anteriormente, para crear un paquete WEP valido, se debe utilizar la función CRC32 para chequear la integridad del paquete y de esta forma generar un ICV “parcheado”, pues partiendo de esta premisa, se intenta determinar cual es el valor real del ultimo byte eliminado intentando probar todas las combinaciones de dicho byte, generando un ICV parcheado y enviándolo al AP, posteriormente si la respuesta del AP es positiva se puede determinar que el ICV que se ha generado es valido, por lo tanto se puede deducir que se ha descifrado una “pequeña” parte del paquete y ahora se conoce el texto plano del ultimo byte correspondiente al segmento de datos cifrados (se trata de un progreso significativo). Ahora que es lo que impide que se repita este mismo proceso para todos los demás bytes desde el penúltimo hasta el primero? Absolutamente nada. Es posible repetir este mismo procedimiento para el resto de bytes localizados en la sección de datos cifrados hasta que se consiga descifrar completamente el paquete. La siguiente imagen explica este mecanismo de forma un poco más clara.

  4. Ahora bien, el ICV generado por la función CRC32 será perfectamente valido para el AP en el caso de que el ultimo byte que se haya indicado sea el que corresponde al paquete original, en otro caso, el AP simplemente descartará dicho paquete. Cada uno de estos paquetes es generado y enviado al AP a la dirección de multicast

  5. Como se ha dicho anteriormente, este procedimiento se repite de forma constante hasta que se consigue descifrar cada uno de los bytes contenidos en el paquete.

Ahora que se ha comprendido como funciona realmente el ataque Chopchop, se puede proceder a utilizar (nuevamente) Aircrack-ng para reproducir este ataque. Como se ha dicho anteriormente, estos comandos son bastante fáciles de ejecutar, por esta razón el hacking wireless atrae a tantos script kiddies, sin embargo se repite nuevamente, el hecho de conocer lo que se esta haciendo es lo que diferencia a un hacker de un lammer, el conocimiento es el factor diferenciador. Supongo que esta es la mejor lección que se puede extraer de este blog.

Sin más preámbulos se procede a realizar una prueba practica utilizando Aircrack-ng.

En primer lugar, se asume que se ha iniciado la interfaz de red en modo monitor y se identifica el SSID que tenga cifrado WEP. Posteriormente se emplea el comando “aireplay-ng” de la siguiente manera:

>aireplay-ng –4 -e SSID_WEP mon0

El número 4 indica el identificador de aircrack-ng para el ataque chopchop, sin embargo también se puede especificar la opción “– chopchop” para mayor claridad. A efectos prácticos es igual. Ahora bien, es posible que algunos AP no reciban paquetes de cualquier cliente cuya dirección MAC no se encuentre previamente autenticada, en tales casos se recibirá un mensaje de error similar al siguiente:

Failure: the access point does not properly discard frames with an

invalid ICV – try running aireplay-ng in authenticated mode (-h) instead.

Tal como el mensaje indica, es necesario utilizar la MAC de un cliente que se encuentre autenticado y posteriormente intentar realizar nuevamente el ataque de la siguiente forma:

>aireplay-ng –chopchop -e SSID_WEP -h e8:3e:b6:91:61:74 mon0

En este punto aircrack-ng intentará leer y capturar un paquete valido (evidentemente los paquetes Probe request o Probe response no son útiles) una vez que aircrack-ng captura un paquete de datos valido se verá una salida similar a la siguiente:

Read 2194 packets…

Size: 69, FromDS: 0, ToDS: 1 (WEP)

BSSID = 00:19:15:CE:42:2A

Dest. MAC = 00:19:15:CE:42:2A

Source MAC = E8:3E:B6:91:61:74

0x0000: 0859 3a01 0019 15ce 422a e83e b691 6174 .Y:…..B*.>..at

0x0010: 0019 15ce 422a 3096 d2ba ec00 930d 7226 ….B*0…….r&

0x0020: 6831 15df c552 69ab f2f2 247e 582e df75 h1…Ri…$~X..u

0x0030: fc7f cd19 02c5 643c 4823 1a08 dec1 399b .….d<H#….9.

0x0040: 6a88 7412 4e j.t.N

Use this packet ?

y

Saving chosen packet in replay_src-0228-231023.cap

Offset 68 ( 0% done) | xor = 65 | pt = 2B | 181 frames written in 3069ms

Offset 67 ( 2% done) | xor = 41 | pt = 53 | 84 frames written in 1424ms

……… SNIP ………..

Saving plaintext in replay_dec-0228-231234.cap

Saving keystream in replay_dec-0228-231234.xor

Completed in 78s (0.40 bytes/s)

El paquete se ha descifrado completamente y ahora puede abrirse con wireshark el fichero pcap generado. La siguiente imagen enseña su contenido:

El paquete es simplemente un ICMP que se ha realizado desde una máquina en el segmento de red hacia el AP. Este mecanismo evidentemente puede llevarse a cabo en repetidas ocasiones y capturar cualquier tipo de paquete de datos.

En próximas publicaciones más sobre hacking wireless.