Cómo conocí a tu chica & Hole 196
En BlackHat/Defcon siempre hay sesiones curiosas que uno se pierde, pero que, gracias a los que escriben sobre ellas, uno puede volver a asitir varias veces a los eventos.
Aprovechando las referencias que ha habido en la web, y que Dragonjar ha recopilado todas las presentaciones y whitepapers, he repasado una muy curiosa titulada How I met your girlfriend. [white paper, slides]
La idea de la charla es analizar las debilidades en la generación de números aleatorios de sesión en PHP 5.3 y ver como estos adolecen de debilidades que pueden permitir a un atacante predecirlos. Sin embargo, la gracia total de la charla y lo que más ha dado la vuelta al mundo ha sido la aplicación de la prueba de concepto para extraer la MAC del router y pasarla por la base de datos de MAC y posiciones GPS creadas por el cochecito del Google Street View para decirte donde vives.
Figura 1: MACXSS POC
Samy Kamkar ha puesto una prueba de concepto de esto online, que puedes probar. Desde Internet Explorer 8 no tira, pero si le das a alguno de los otros Web Browsers podrás verlo. La idea es muy chula.
WPA Too
La segunda charla de la que quiero hablaros es de la famosa Hole 196 de la WiFi. Tras un poco de lío con las informaciones previas, la idea del ataque es tan sencilla como peculiar.
En la página 196 del estándar dice que los mensajes enviados con claves de grupo, es decir, las claves pensadas para comunicaciones broadcast no tienen protección contra Spoofing. Así, un atacante puede enviar un mensaje con una clave GTK con la IP que quiera.
Figura 2: Distribució de claves en WPA/WPA2
La gracia del ataque es enviar un mensaje con una clave GTK pero a una MAC dirigida en lugar de a una dirección MAC de broadcasting. Haciendo esto, sólo la víctima procesará ese paquete broadcast y, por tanto, salvo que la tabla de ARPs tenga la resolución de la MAC del Gateway estática, se producirá una envenenamiento de la IP que permitirá suplantar al router.
A partir de ese momento, cuando la víctima se comunique con el Gateway se utilizarán las claves PTK asociadas a esa IP, que el atacante amáblemente entregará para hacer el MITM. Simple, pero funcional.
No rompe el sistema de autenticación de WPA/WPA-2 Enterprise, pero ayuda a hacer ataques MITM en esos entornos de forma oculta. La gracia es que el paquete va cifrado con la GTK y a una MAC que no es de broadcast lo que haría que, hasta que no aparezcan soluciones IDS que inspeccionen todo el tráfico que vaya cifrado con claves GTK aunque no vaya a MAC de broadcast, el ataque no sea descubierto. Tienes el paper en la siguiente URL: WPA Too Hole 196 white paper y todos los materiales de la Defcon18 publicados aquí.
Ale, para que luego digas que no viniste a las charlas ;)
Saludos Malignos!
Aprovechando las referencias que ha habido en la web, y que Dragonjar ha recopilado todas las presentaciones y whitepapers, he repasado una muy curiosa titulada How I met your girlfriend. [white paper, slides]
La idea de la charla es analizar las debilidades en la generación de números aleatorios de sesión en PHP 5.3 y ver como estos adolecen de debilidades que pueden permitir a un atacante predecirlos. Sin embargo, la gracia total de la charla y lo que más ha dado la vuelta al mundo ha sido la aplicación de la prueba de concepto para extraer la MAC del router y pasarla por la base de datos de MAC y posiciones GPS creadas por el cochecito del Google Street View para decirte donde vives.
Figura 1: MACXSS POC
Samy Kamkar ha puesto una prueba de concepto de esto online, que puedes probar. Desde Internet Explorer 8 no tira, pero si le das a alguno de los otros Web Browsers podrás verlo. La idea es muy chula.
WPA Too
La segunda charla de la que quiero hablaros es de la famosa Hole 196 de la WiFi. Tras un poco de lío con las informaciones previas, la idea del ataque es tan sencilla como peculiar.
En la página 196 del estándar dice que los mensajes enviados con claves de grupo, es decir, las claves pensadas para comunicaciones broadcast no tienen protección contra Spoofing. Así, un atacante puede enviar un mensaje con una clave GTK con la IP que quiera.
Figura 2: Distribució de claves en WPA/WPA2
La gracia del ataque es enviar un mensaje con una clave GTK pero a una MAC dirigida en lugar de a una dirección MAC de broadcasting. Haciendo esto, sólo la víctima procesará ese paquete broadcast y, por tanto, salvo que la tabla de ARPs tenga la resolución de la MAC del Gateway estática, se producirá una envenenamiento de la IP que permitirá suplantar al router.
A partir de ese momento, cuando la víctima se comunique con el Gateway se utilizarán las claves PTK asociadas a esa IP, que el atacante amáblemente entregará para hacer el MITM. Simple, pero funcional.
No rompe el sistema de autenticación de WPA/WPA-2 Enterprise, pero ayuda a hacer ataques MITM en esos entornos de forma oculta. La gracia es que el paquete va cifrado con la GTK y a una MAC que no es de broadcast lo que haría que, hasta que no aparezcan soluciones IDS que inspeccionen todo el tráfico que vaya cifrado con claves GTK aunque no vaya a MAC de broadcast, el ataque no sea descubierto. Tienes el paper en la siguiente URL: WPA Too Hole 196 white paper y todos los materiales de la Defcon18 publicados aquí.
Ale, para que luego digas que no viniste a las charlas ;)
Saludos Malignos!
5 comentarios:
A partir de ese momento, cuando la víctima se comunique con el Gateway se utilizarán las claves PTK asociadas a esa IP, que el atacante amáblemente entregará para hacer el MITM.
No termino de entenderlo. En un entorno 802.11x, para generar la PTK, se necesita la PMK, que sólo conocen el cliente, el RADIUS y el PA (cuando el RADIUS se la envía). En ese momento, PA y cliente intercambian Anonce y Snonce y derivan la PTK.
Si tras recibir el mensaje GTK manipulado desde el atacante, se genera una nueva PTK, ¿cómo conoce el atacante la PMK?
@chen,
como bien dices, al final, el cliente pide a la MAC spoofeada la PTK, y el malo le da la supuesta PTK del Gateway (que es la suya). Eso es todo.
Saludos!
@Maligno
Vale, era así de sencillo :-)
Hola Chema,
lo que dices en tu comentario no es correcto. El atacante nunca da su PTK a nadie; lo que sucede es que al haber realizado un envenenamiento ARP, la víctima contacta con el AP cifrando las tramas con su PSK, el AP las descifra, y se las envía al atacante cifrado con su PSK. Por supuesto el atacante puede descifrarlo y tiene acceso a los datos.
Es decir, las tramas de las STA envenenadas acaban pasando por el AP y finalmente son entregados al atancante (en cada momento utiliza el correspondiente PTK).
Pero eso es muy diferente a lo que comentaste.
Un saludo y a seguir con el blog, que vale la pena :)
Los dos casos donde pone PSK quería decir PTK.
Sorry
Publicar un comentario