Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
El minuto de la WiFi
Muchos son los sitios que se están haciendo eco del trabajo que han realizado unos investigadores japoneses para vulnerar la seguridad de la WiFi. En muchos titulares se pueden leer cosas como que la WiFi en WPA se crackea en menos de 1 minuto o que es el fin del apocalipsis, o que la WiFi casera está muerta o cosas así. Pero esto dista un poco de la realidad. Como siempre....A ver si soy capaz de explicar este paper sin perderme yo y perderos a vosotros.
La historia comienza con el ataque chopchop a TKIP que ya os resumí en otro post no tiempo ha. En ese trabajo, el atacante es el cliente de la WiFi e intenta, sin conocer la clave WPA-PSK, mediante un ataque chopchop a un paquete ARP conseguir un Keystream válido. La idea es que para hacer el ataque chopchop se fija un valor IV/TSC. El ataque termina cuando se ha tenido éxito, es decir, cuando el paquete del IV/TSC ha sido interpretado por el AP, respondido y, por tanto, incrementado el IV/TSC. A partir de ese momento, no se puede enviar ningún paquete con el mismo canal con el mismo valor de IV/TSC, con lo que la clave de cifrado de este paquete no puede volver a utilizarse… por ese canal. De ahí que, en el trabajo de Beck-Tews, se habla de usar los canales multimedia del protoloco 802.1e para poder meter 1 paquete por cada uno de los otros canales con el keystrem válido de ese IV/TSC.
Si ese ataque se quisiera hacer entre un cliente conectado y un AP válido, habría que bloquear todas las comunicaciones para evitar que el IV/TSC que se está probando sea utilizado por el cliente legítimo y, por tanto, inutilizado antes de que se obtenga el keystream asociado. Esto hacía que, en entornos MITM, el cliente, al pasar entre 12 y 15 minutos de tiempo sin recibir notificaciones del AP, cortara la conexión por time-out. En este nuevo paper, titulado "A Practical Message Falsication Attack on WPA" añaden algún truco chulo a este entorno para conseguir alguna mejora.
1.- El ataque sigue siendo MITM en WiFi, así que hay que bloquear todo el tráfico entre el cliente y el AP para que no se usen los IV/TSC. Esto implica el uso de antenas direccionales.
2.- Para conseguir que no se desconecte el cliente del AP se repiten las beacom frames, es decir, el cliente recibe señal del AP, pero sólo señal que no cambia los IV/TSC. Este es un buen truco para saltarse el problema de que el cliente detecte el ataque por desconexión. La WiFi no se cae.
3.- Cuando el cliente envía un paquete pequeño tipo ARP que se puede crackear con un ataque chopchop en un tiempo “útil”, el atacante empieza, con el IV y el TSC, a intentar el ataque chopchop que dura, como dice el paper, entre 12 y 15 minutos, entre el atacante y el cliente.
3.1- Si tiene éxito y se tiene un keystream válido se calcula un MIC válido para el paquete que se quiere inyectar. Este ataque dura aproximadamente 4 minutos.
3.2.- Una vez que se tiene el KesyStream y el MIC válido, se puede inyectar 1 paquete del cliente al servidor, ya que, como ha sido bloqueado, no se ha utilizado ese IV con el servidor. Esto evita el uso de los canales de 802.1e.
Lógicamente, si se usan los canales, el número de paquetes que se puede inyectar es mayor, ya que se podría meter 1 por canal y hay que tener en cuenta que el ataque puede ser una vez entre el cliente y el atacante, y otra vez entre el atacante y el AP.
4.- Si mientras que se está realizando el ataque chopchop llega un paquete de aplicación grande, a día de hoy no explotable en tiempo útil por el ataque chopchop, se interrumpe el ataque chopchop que se está realizando y se deja pasar el paquete de aplicación. Esto implica que todo lo hecho en el ataque chopchop ya no vale, porque se ha usado el IV/TSC, y hay que empezar de nuevo con el siguiente paquete chopchop-eable.
En definitiva, es un muy buen truco, un muy buen punto de avance que abre muchas puertas pero no saca la clave de conexión WPA-PSK, por supuesto sólo es para TKIP, ya que se basa en el ataque chopchop TKIP, con lo que se puede seguir confiando en WPA2-PSK y en soluciones WPA/WP2-Enterprise… de momento.
El paper del ataque está disponible en la siguiente URL: A Practical Message Falsication Attack on WPA
Saludos Malignos!
La historia comienza con el ataque chopchop a TKIP que ya os resumí en otro post no tiempo ha. En ese trabajo, el atacante es el cliente de la WiFi e intenta, sin conocer la clave WPA-PSK, mediante un ataque chopchop a un paquete ARP conseguir un Keystream válido. La idea es que para hacer el ataque chopchop se fija un valor IV/TSC. El ataque termina cuando se ha tenido éxito, es decir, cuando el paquete del IV/TSC ha sido interpretado por el AP, respondido y, por tanto, incrementado el IV/TSC. A partir de ese momento, no se puede enviar ningún paquete con el mismo canal con el mismo valor de IV/TSC, con lo que la clave de cifrado de este paquete no puede volver a utilizarse… por ese canal. De ahí que, en el trabajo de Beck-Tews, se habla de usar los canales multimedia del protoloco 802.1e para poder meter 1 paquete por cada uno de los otros canales con el keystrem válido de ese IV/TSC.
Si ese ataque se quisiera hacer entre un cliente conectado y un AP válido, habría que bloquear todas las comunicaciones para evitar que el IV/TSC que se está probando sea utilizado por el cliente legítimo y, por tanto, inutilizado antes de que se obtenga el keystream asociado. Esto hacía que, en entornos MITM, el cliente, al pasar entre 12 y 15 minutos de tiempo sin recibir notificaciones del AP, cortara la conexión por time-out. En este nuevo paper, titulado "A Practical Message Falsication Attack on WPA" añaden algún truco chulo a este entorno para conseguir alguna mejora.
1.- El ataque sigue siendo MITM en WiFi, así que hay que bloquear todo el tráfico entre el cliente y el AP para que no se usen los IV/TSC. Esto implica el uso de antenas direccionales.
2.- Para conseguir que no se desconecte el cliente del AP se repiten las beacom frames, es decir, el cliente recibe señal del AP, pero sólo señal que no cambia los IV/TSC. Este es un buen truco para saltarse el problema de que el cliente detecte el ataque por desconexión. La WiFi no se cae.
3.- Cuando el cliente envía un paquete pequeño tipo ARP que se puede crackear con un ataque chopchop en un tiempo “útil”, el atacante empieza, con el IV y el TSC, a intentar el ataque chopchop que dura, como dice el paper, entre 12 y 15 minutos, entre el atacante y el cliente.
3.1- Si tiene éxito y se tiene un keystream válido se calcula un MIC válido para el paquete que se quiere inyectar. Este ataque dura aproximadamente 4 minutos.
3.2.- Una vez que se tiene el KesyStream y el MIC válido, se puede inyectar 1 paquete del cliente al servidor, ya que, como ha sido bloqueado, no se ha utilizado ese IV con el servidor. Esto evita el uso de los canales de 802.1e.
Lógicamente, si se usan los canales, el número de paquetes que se puede inyectar es mayor, ya que se podría meter 1 por canal y hay que tener en cuenta que el ataque puede ser una vez entre el cliente y el atacante, y otra vez entre el atacante y el AP.
4.- Si mientras que se está realizando el ataque chopchop llega un paquete de aplicación grande, a día de hoy no explotable en tiempo útil por el ataque chopchop, se interrumpe el ataque chopchop que se está realizando y se deja pasar el paquete de aplicación. Esto implica que todo lo hecho en el ataque chopchop ya no vale, porque se ha usado el IV/TSC, y hay que empezar de nuevo con el siguiente paquete chopchop-eable.
En definitiva, es un muy buen truco, un muy buen punto de avance que abre muchas puertas pero no saca la clave de conexión WPA-PSK, por supuesto sólo es para TKIP, ya que se basa en el ataque chopchop TKIP, con lo que se puede seguir confiando en WPA2-PSK y en soluciones WPA/WP2-Enterprise… de momento.
El paper del ataque está disponible en la siguiente URL: A Practical Message Falsication Attack on WPA
Saludos Malignos!
4 comentarios:
No me cuadra, los mocés de SbD comentan que cae en 1 minuto, pero tu dices que se tardan casi 20, el paper todavia no me lo he leido, pero si que vi la noti publicada y nombraban de nuevo el famoso minuto.
Pero si realmente se tardan casi 20, y antes se hacia en 12-15... ¿donde esta la gracia del asunto?
Eso lo de beacoM como va? Con mantequilla y huevos fritos? Es broma jajajaj. A le a mandar y a hacer maldades.
Captcha: cochava
Nombre hebreo que significa Estrella, toma castaña ya estan aqui los judios XD.
Es curioso, pero después de leer varias veces el paper (y asumiendo que hay cosas que todavía se me escapan), lo que se ha montado por la frase “Therefore, about 37% of the encrypted ARP packets are recovered by our attack with about one minute”, y me explico:
El paper propone por un lado el tema de MiTM que comenta Chema en el POST, y por otro lado una reducción de tiempo en la extracción del keystream de cifrado en una trama ARP Request cifrada con TKIP.
A modo de resumen, en una trama ARP Request cifrada se desconocen el último byte de la ip de origen y destino (2 bytes), el MIC (8 bytes) y el checksum (4 bytes). Para averiguar el MIC y checksum se utiliza el ataque chop-chop, que tarda aproximadamente 11 minutos, tanto en el ataque anterior como en este, PASO IMPRESCINDIBLE.
La segunda parte consiste en obtener los dos bytes del paquete ARP, 2 a la 16 posibles paquetes ARP distintos que con el MIC se genera el checksum y se compara con los obtenidos por chop-chop, se van descartando los que no coinciden hasta que no quedamos con uno. Proceso que tarda unos 4 min y nos permite sacar el keyStream de cifrado de la trama para poder construir un paquete falso valido.
Propuesta del paper: fijemos el último byte de la dirección IP de destino (la del AP que suele ser fija), y tendremos 2 a la 8 posibles paquetes ARP, y comparemos únicamente el último byte de los 4 del checksum para descartar paquetes. Conclusión tenemos un 37% de posibilidades de completar esta segunda fase en 1 minuto.
¿Mis conclusiones?, mola el tema del MiTM (evita el QoS), aunque habrá que ver la “facilidad” de llevarlo a cabo, y la reducción del tiempo, pues bueno no me parece lo más interesante… Y lo de que se rompe en un minuto, pues eso, o me he bajado otro paper o no me he enterado de nada …
Saludos
¿Hay algun programa que utilice este ataque? o quizá, ¿habrá alguien que lo esté haciendo?
Publicar un comentario