WPA + TKIP. Probando con tkiptun-ng

editado junio 2009 en Seguridad Wireless
Bien, aquí va la primera prueba wink.gif lo prometido es deuda biggrin.gif

El escenario es un tanto extraño… tenemos una red WiFi + WPA + TKIP + QoS con clientes asociados…

En esa misma red hay equipos conectados por cable (uno de ellos el del atacante) que además dispone de una tarjeta inalámbrica (realmente tengo dos pero sólo entra en juego una de ellas, la otra actua como esnifer para monitorizar el tráfico y así comprendo mejor como rula todo),

eth0 es la tarjeta de cable
eth1 es la tarjetra wifi por la que se inyectará el tráfico
wlan0 es la tarjeta wifi por la que monitorizo el tráfico durante el ataque

Código: bt src # ifconfig
eth0 Link encap:Ethernet HWaddr 00:A0:CC:D0:EB:5A
inet addr:10.10.10.202 Bcast:10.10.10.255 Mask:255.255.255.0
inet6 addr: fe80::2a0:ccff:fed0:eb5a/64 Scope:Link
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:124285 errors:0 dropped:0 overruns:0 frame:0
TX packets:61671 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:151309283 (144.2 MiB) TX bytes:10397372 (9.9 MiB)
Interrupt:10 Base address:0xd000

eth1 Link encap:UNSPEC HWaddr 00-02-6F-35-DE-56-30-3A-00-00-00-00-00-00-00-00
inet6 addr: fe80::202:6fff:fe35:de56/64 Scope:Link
UP BROADCAST NOTRAILERS RUNNING PROMISC ALLMULTI MTU:1500 Metric:1
RX packets:82686808 errors:0 dropped:0 overruns:0 frame:0
TX packets:55251 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4292120795 (3.9 GiB) TX bytes:4112136 (3.9 MiB)
Interrupt:11

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:17 errors:0 dropped:0 overruns:0 frame:0
TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1442 (1.4 KiB) TX bytes:1442 (1.4 KiB)

wlan0 Link encap:UNSPEC HWaddr 00-18-E7-55-B2-FF-30-3A-00-00-00-00-00-00-00-00
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:9010620 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1438671720 (1.3 GiB) TX bytes:0 (0.0 b)

El atacante desconoce la contraseña WPA de los clientes inalámbricos.

Se trata de conseguir enviar un ARP “trucado” desde el equipo atacante y POR LA RED INALAMBRICA de la cual desconocemos la contraseña WPA. Y digo "trucado" porque no es un arp al estilo arp-spoof... es ... bueno luego lo analizáis... cool.gif

Puse en mayúsculas lo de la red inalámbrica, porque todo este berenjenal bien se podría hacer desde la misma tarjeta de cable, pero no es lo que se pretende, sencillamente hay que “demostrar” que se puede enviar tráfico a la red wifi y modificar la caché arp de la víctima para que pase por el equipo atacante o para sencillamente provocar un DoS.. a todos??

Para ello he modificado el código de tkiptun-ng que ya vamos conociendo… y en lugar de enviar ARP RQST al broadcast (que es lo que hace en su forma original) envio ARP Response y Request trucados…

A partir de ese momento el tráfico de salida de la víctima pasará por nosotros, no el de vuelta, puesto que se lo dará el AP al cliente, pero para empezar no está mal biggrin.gif

Estoy usando una Live CD (BT2) que tiene “algún” que otro problema con este escenario, concretamente y ya que no podemos hacer un arp-spoof completo (recuerda que sólo vamos a poder esnifar en una sola dirección) envía una serie de icmp-redirects que nos van a fastidiar el asunto… así que o los desactivamos o los bloqueamos con iptables (opción que elegí para que poco a poco pueda dejar los icmp-redirec que me interesen, de momento todos fuera)

Código: iptables -A INPUT -i eth0 -p icmp --icmp-type redirect -j DROP
iptables -A OUTPUT -o eth0 -p icmp --icmp-type redirect -j DROP
iptables -A FORWARD -i eth0 -p icmp --icmp-type redirect -j DROP

También tenemos que “bloquear” nuestros propios ARP REQUEST buscando al router o al cliente víctima porque si no también se nos fastidia el invento… ahora es mas facil crear una entrada estática en la caché arp

Código: arp -s 10.10.10.245 00:16:B6:41:03:5B
arp -s 10.10.10.200 00:17:9A:C3:D6:B9

Con todo esto ya preparado, sólo queda lanzar tkiptun-ng (como el “mio” está tocado le llamé tkiptun2-ng y mantener el original) de esta forma:

Código: ./tkiptun2-ng -a 00:16:B6:41:03:5D -h 00:17:9A:C3:D6:B9 -m 80 -n 100 eth1 -e WCASA -t 0 -f 1

Donde:

-a es el bssid del punto de acceso
-h es la mac de la víctma
-m 80 y –n 100 es el tamaño mínimo y máximo de cada paquete que usaremos
eth1 pues eso… la tarjeta inalámbrica
-w WCASA el essid de la red WPA
-t 0 y –f1 son los flags de trama que indican que van del punto de acceso al cliente.

Esto último es importante, muchas veces la gente se lía (sobretodo mis alumnos al principio) y es muy sencillo, estos indicadores son los conocidos como toDS y fromDS y pueden estar activados o desactivados dependiendo de quien y hacia donde envía el tráfico, para hacerlo simple:

toDS=0 y fromDS=0 para comunicaciones ad-hoc
toDs=0 y fromDS=1 comunicación del punto de acceso al cliente
toDS=1 y fromDS=0 comunicación de la estación al punto de acceso
toDS=1 y fromDS=1 comunicación entre puntos de acceso

(bueno, estaría mejor dicho desde o hacia el Sistema de Distribución… pero de la forma de arriba se entiende mejor)

El caso es que una vez lanzado (eso tardará como un cuarto de hora) podemos ir anotando los datos que necesitaremos y también pondremos a escuchar a tcpdump en otra shell para comprobar que cuando todo finalice estemos “en medio” aunque sea “a medias”

Necesitamos (porque las modificaciones que hice nos lo pedirá antes de inyectar los paquetes) esto:

Código: MAC del atacante: 00:A0:CC:D0:EB:5A

IP del Router: 10.10.10.245

MAC de la víctima: 00:16:B6:41:03:5B

Os pego el código de salida tal cual:

Código: bt src # ./tkiptun2-ng -a 00:16:B6:41:03:5D -h 00:17:9A:C3:D6:B9 -m 80 -n 100 eth1 -e WCASA -t 0 -f 1
The interface MAC (00:02:6F:35:DE:56) doesn't match the specified MAC (-h).
ifconfig eth1 hw ether 00:17:9A:C3:D6:B9
Blub 2:38 E6 38 1C 24 15 1C CF
Blub 1:17 DD 0D 69 1D C3 1F EE
Blub 3:29 31 79 E7 E6 CF 8D 5E
02:05:08 Michael Test: Successful
02:05:08 Waiting for beacon frame (BSSID: 00:16:B6:41:03:5D) on channel 1
02:05:08 Found specified AP
02:05:08 Sending 4 directed DeAuth. STMAC: [00:17:9A:C3:D6:B9] [ 1| 0 ACKs]
02:05:13 WPA handshake: 00:16:B6:41:03:5D captured
02:05:13 Waiting for an ARP packet coming from the Client...
Saving chosen packet in replay_src-0620-020513.cap
02:05:13 Waiting for an ARP response packet coming from the AP...
Saving chosen packet in replay_src-0620-020513.cap
Saving chosen packet in replay_src-0620-020514.cap
02:05:14 Got the answer!
02:05:14 Waiting 10 seconds to let encrypted EAPOL frames pass without interfering.

02:05:29 Offset 81 ( 0% done) | xor = 89 | pt = 09 | 51 frames written in 41845ms
02:06:43 Offset 80 ( 2% done) | xor = 3B | pt = A6 | 126 frames written in 103320ms
Looks like mic failure report was not detected.Waiting 60 seconds before trying again to avoid the AP shutting down.
02:09:33 Offset 79 ( 4% done) | xor = 06 | pt = FD | 466 frames written in 382120ms
02:10:51 Offset 78 ( 7% done) | xor = D4 | pt = 45 | 169 frames written in 138580ms
02:12:16 Offset 77 ( 9% done) | xor = 61 | pt = 28 | 234 frames written in 191880ms
02:13:23 Offset 76 (11% done) | xor = F9 | pt = D9 | 60 frames written in 49199ms
02:14:47 Offset 75 (14% done) | xor = E9 | pt = C4 | 225 frames written in 184501ms
02:16:13 Offset 74 (16% done) | xor = 3E | pt = 25 | 241 frames written in 197617ms
02:17:27 Offset 73 (19% done) | xor = 6D | pt = 1F | 133 frames written in 109061ms
Looks like mic failure report was not detected.Waiting 60 seconds before trying again to avoid the AP shutting down.
02:20:00 Offset 72 (21% done) | xor = 95 | pt = 68 | 298 frames written in 244364ms
02:21:23 Offset 71 (23% done) | xor = B3 | pt = F9 | 219 frames written in 179577ms
02:22:49 Offset 70 (26% done) | xor = DB | pt = C2 | 243 frames written in 199260ms
Sleeping for 60 seconds.36 bytes still unknown
ARP Reply
Checking 192.168.x.y
Checking 10.0.y.z
Checking 172.16.y.z
02:26:19 Offset 69 (28% done) | xor = 92 | pt = C8 | 218 frames written in 178760ms
Sleeping for 60 seconds.35 bytes still unknown
ARP Reply
Checking 192.168.x.y
Checking 10.0.y.z
02:26:21 Reversed MIC Key (FromDS): B8:8A:6D:39:31:60:D3:88

Saving plaintext in replay_dec-0620-022621.cap
Saving keystream in replay_dec-0620-022621.xor
02:26:21
Completed in 1257s (0.03 bytes/s)

02:26:21 AP MAC: 00:16:B6:41:03:5B IP: 10.10.10.245
02:26:21 Client MAC: 00:17:9A:C3:D6:B9 IP: 10.10.10.200


Escribe MAC (falsa o del atacante): 00:A0:CC:D0:EB:5A

Escribe IP del Router/Punto de acceso): 10.10.10.245

Escribe MAC de la víctima: 00:16:B6:41:03:5B

Enviando una trama de datos x minuto .

88 42 2C 00 00 17 9A C3 D6 B9 00 16 B6 41 03 5D
00 A0 CC D0 EB 5A D0 B4 02 00 00 20 04 20 00 00
00 00 BD 07 04 7E 2B 93 DD 36 83 A1 E4 AB D2 DD
8F C7 70 C1 11 6C E9 EF 27 D1 AB 16 34 42 9D A9
DC D1 E0 E3 0D 5A E4 2A 59 7B 14 12 E3 88 E0 B1
23 EC

02:27:06
Enviado ARP RESPONSE-REQUEST encriptado tkip al cliente

En la víctima puse otro esnifer… estaría bien dedicarle un tiempo a explicar lo que se envía y lo que se recibe, pero para este ejmplo nos basta con el paquete nº 31


img01q.jpg
img02d.jpg

Ahora vamos desde la víctima a hacer un ping a una dirección de Internet

Código: Ping 195.235.113.3

Y en la ventana del tcpdump que os dije que pusiéramos antes… ohhhhh!!!

Código: bt ~ # tcpdump -i eth0 -p icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
02:27:26.483936 IP 10.10.10.200 > dns.terra.es: ICMP echo request, id 1024, seq 19714, length 40
02:27:26.617772 IP 10.10.10.200 > dns.terra.es: ICMP echo request, id 1024, seq 19714, length 40

Como véis se ha inyectado un falso arp por eth1 (wifi) sin conocer la clave WPA y recibimos las respuesta por eth0… y tal y como os avance…sólo cazamos el tráfico en una dirección…. Pero todo se andará biggrin.gif

Hace unos miles de años se pensaba que la Tierra era "plana", se la imaginaban como una gran superficie y en los bordes... El Gran Abismo.

Cientos de años después, La Tierra ya era "como redonda" pero seguían obcecados en que era el centro del universo y que todo giraba entorno a ella.

A finales del siglo XIX algunos de los grandes pensadores e investigadores de la época estaban "apesadumbrados", creían que "ya no había mas que inventar, que ya estaba todo inventado".

Con esto quiero decir (como escenificaba el "gag") No disparen al pianista.... o mejor dicho y mejor traído a como empezaba... No queméis a Galileo.

Y si os dijese que no es sólo una "debilidad" suscitada por el protocolo 802.11e (QoS), y si esto mismo se puede aplicar a Redes WPA+TKIP "sin QoS"???

Pues si seguimos "quemando a Galileo" diremos que "ahh!!! pero sólo es si utilizo WPA+TKIP, si cambio a WPA2 o utilizo AES pues nada...."

Resultará que mas adelante, días-meses-años, también esos otros protocolos y sistemas de protección se verán afectdos, por esto o por algo similar... y entonces diremos que hay que usar WPA2+vete-a-saber.

Esto no es mas que la punta del iceberg, posiblemente vendrán nuevas formas, nuevos ataques, no quememos a Galileo...

Vamos a dar un paso atrás para ver todo con perspectiva, estudiando, analizando, probando y sin afirmaciones categóricas. Cierto que hoy en día "nos quedamos con las ganas" de obtener la clave WPA, que por el momento sólo sirve para inyectar paquetes... o no?

Por supuesto que os pasaré el código para que lo podáis compilar, probar y mejorar... me tendréis que dejar unos días puesto que quiero "depurarlo" y hacer que funcione sin QoS habilitado...

Mientras tanto y para que los programadores (que los hay muy buenos por aquí y con muchísimos mas conociemientos que yo) podáis ir metiendo mano al fuente de tkiptun-ng, os cuento como funciona el ataque (también lo ha preguntado alguno en este hilo) y algunas cuestiones importantes a tener en cuenta.

Resumiendo mucho:
    * El atacante
captura tráfico ARP y obtiene las direcciones MAC origen y destino que no son cifradas,

* Las direcciones de red IP (para IP4) tampoco son cifradas con la excepción del último byte (así es como está implementado el estandar de protocolo).

* También se capturan los 8 bytes del algoritmo de MICHAEL el MIC, ambos, sirven para comprobar si una trama fue o no modificada en tránsito o si ha sido alterada en el origen.

* En el paquete esnifad, también hay un checksum generado para cada ICV de 48bits (así funciona TKIP) de modo que:
    +
TKIP es Protocolo de Integridad de Clave Temporal
+ Utiliza 4 claves distintas entre Punto de Acceso y cada Cliente Wireless para tráfico Unicast y 2 claves para tráfico broadcast y/o multicast.
+ Esas claves temporales las podréis encontrar con el nombre PKT (para unicast) y GKT (broadcast y multicast).
+ Las claves se recalculan para cada paquete con una función de mezclado para cada paquete
+ Calcula un “Message Integrity Code” (MIC) de 8 bytes
+ Estos 8 bytes se introducen entre los datos y los 4 Bytes del ICV de la trama 802.11
+ Se cifra junto con los datos y el ICV
+ Si se detecta un MIC incorrecto se asume que hubo un "ataque" o problemas....
+ Si hay mas de 2 errores de este tipo en un minuto (60 segundos desde el último MIC incorrecto detectado) se renegocian las claves (y el ataque se irá a la porra porque el MIC habrá cambiado)
+ Existe un valor llamado TSC (Contador de Tiempo de Secuencia) que sirve para evitar los ataques del tipo reinyección y también para evitar que paquetes "viejos" sean reenviados.



Entonces... cómo es posible el ataque??

Pues por lo siguiente:

    * El atacante
captura un ARP Request o Response (se eligen estos paquetes porque son pequeños y así no hay "mucho" que descifrar después).

* El atacante obtiene ese "byte" cifrado del que hablaba antes probando todas las combinaciones para ese byte (256 desde 0x00 a 0xFF) y si una "acierta" el punto de acceso informará diciendo que existe un error en el MIC (porque no conocemos el "bueno").

* En este punto ya tenemos un byte "descifrado" pero hemos de esperar al menos 60 segundos puesto que si repetimos la operación y segun lo explicado anteriormente de cómo funciona TKIP si se detecta otro MIC incorrecto en el "mismo minuto" las claves se renegocian y cambia todo el escenario... hay que volver a empezar, las estaciones se "desconectan" y otra vez...

* tras esperar ese minuto, se vuelve a probar las 256 posibilidades para otro byte cifrado, si se encuentra... un minuto de espera y a por el tercero...

* Por esto se "toman" paquetes ARP, son pequeños y sólo hay que ocuparse de 14bytes cifrados correspondientes a:

    1 byte (el último) para la dirección IP origen 1 byte (el último) de la dirección ip destino 8 bytes del MIC 4 bytes de para el checksum de ICV


Por esto de los MIC's fallidos es por lo que se recomienda "rebajar" el tiempo de renegociación de las claves temporales (por defecto 3600 seg). si lo bajamos a 300 seg el atacante podría en el mejor de los casos descifrar 5 bytes, que son insuficientes)

También por lo mismo, el ataque "dura" unos 15 minutos... hay que esperar a que el punto de acceso no tome contramedidas contra MIC's erróneos.

Y la pregunta que habéis hecho... ¿por qué QoS?

QoS utiliza canales o colas para priorizar el tráfico de datos (por eso se llama calidad de servicio) algunos servicios los define el administrador como "mas importantes que otros" y se situan en "colas de espera" en función a su "importancia"

El misterio de este ataque (tal y como está implementado en el código fuente de tkiptun-ng) es usar un canal diferente QoS para enviar el/los paquetes del que fueron recibidos... se utiliza un canal con poco o ningún tráfico, de este modo tenemos un TSC prácticamente "limpio" y los paquetes no son marcados como viejos.

Observa una cosa, puedes pensar que al enviar 256 pruebas para ir "descifrando" byte por byte la trama cifrada, se activen las contramedidas MIC de los 60 segundos... pues NO. Si enviamos paquetes con los bytes "incorrectos" se descartan en silencio, sólo se activa la contramedida de MIC si acertamos en ese byte...

También es importante otra cuestión... acertemos o no acertemos en el envío el TSC no cambia (todavía no hubo un paquete de datos válido) por eso se elije un canal QoS diferente!!!! en el canal original (en el caso de que lleguemos con éxito al final del ataque) nuestro paquete correcto sería viejo... mientras que al elegir un canal "limpio" el TSC no se incrementó y nuestro paquete descifrado es primero y ultimo de la cola.

Por eso funciona muy bien con QoS y bastante mal sin ello... y en eso es lo que estoy... probando... si consigo descifrar un paquete por el mismo método pero sin QoS (esto casi-casi lo tengo) ya sólo queda conocer el próximo TSC válido e inyectarlo en el momento oprtuno (eso creo vamos) ... menuda panzada de protocolo que me estoy dando...

Gracias a la suite de aicrack no hay mucho que programar... mas bien de entender cómo lo han hecho que no es poco... lo que sí importa y bien es que entendáis correctamente el formato de trama para 802.11 (y sus extensiones b,g,e....) porque si ello, ya podéis ser unos malabaristas de lenguaje C que poco sacaréis en claro.

Así que (mientras depuro los programitas) estudiad como es la comunicación "normal" sin ataques ni cosas raras, la posición y el significado de cada bit o de nada servirá el resto.

Saludos.
Fuente

Comentarios

  • editado 4:50
    Seifreed se que este tema ya es bastante viejo pero sigo interesado ya que está estancado desde el año 2009, ¿donde está el famoso tkiptun2-ng que estabas depurando? O quizás este método de crackeo esta desfasado y no lleva a ninguna parte. Un saludo socio.
  • editado 4:50
    Gracias por la informacion
Accede o Regístrate para comentar.