Hace casi un año, ya hablábamos en SbD de cómo el algoritmo de cifrado WPA en su modalidad TKIP, podía ser comprometido en menos de 15 minutos.
Este tipo de cifrado sustituyó a WEP (Wired Equivalent Privacy) como el estándar para el cifrado del tráfico en redes wireless. Posteriormente, surgió WPA2 como evolución reforzada y estandarizada por parte del IEEE como 802.11i (mayor longitud de clave y utilización de AES internamente en vez de RC4 como TKIP).
Bueno, pues dos investigadores de universidades japonesas (Hiroshima y Kobeshi), han descubierto otra manera de llevarse por delante el ya tambaleante WPA. El ataque anterior (Beck-Tews) se basaba en que podías descifrar texto de un paquete y falsificarlo siempre y cuando la implementación de WPA soportara 802.11e (Capacidades QoS). El que plantean los japoneses Toshihiro Ohigashi y Masakatu Morii (espero que a ellos les cueste lo mismo escribir mi nombre que a mí los suyos), permite romper el WPA-TKIP sin estas restricciones. La buena noticia es que el ataque es detectable por el usuario atacado mientras se intenta hacer el man-in-the-middle, puesto que en todo ese rato dicho usuario pierde la conectividad con el resto de la red. El ataque de Beck-Tews demoraba al menos 15 minutos en llevarse a cabo. Sin embargo, en el caso de los japoneses, en el mejor de los casos se tarda 1 minuto (dicha latencia puede achacarse a cualquier problema de red por parte de los usuarios, lo cuál otorga más probabilidades de pasar desapercibido).
El paper de cómo se lleva a cabo el ataque lo podéis descargar de aquí. He podido comprobar que es bastante denso de entender, aunque principalmente lo que dicen es que aplican el ataque Beck-Tews y una serie de inteligentes mecanismos para acelerar el tiempo de ataque de Man-in-the-Middle, posibilitando crackear WPA-TKIP sin el requisito de que soporte QoS según el estándar 802.11e.
¿Qué hacer entonces con las redes wifi?
Bueno, visto que WEP murió hace tiempo y que WPA está cada vez más perdido, la única solución wireless compatible para garantizar la confidencialidad de nuestras conexiones parece ser que es WPA2 o WPA en la modalidad EAP-PEAP-TLS (mediante utilización de certificados)
Como comentamos en el post del año pasado no creo que sea una mala recomendación el encapsulamiento del tráfico de red inalámbrico mediante VPNs convencionales como pueden ser IPSEC o SSL (con la implementación de OpenVPN por ejemplo).
Este tipo de cifrado sustituyó a WEP (Wired Equivalent Privacy) como el estándar para el cifrado del tráfico en redes wireless. Posteriormente, surgió WPA2 como evolución reforzada y estandarizada por parte del IEEE como 802.11i (mayor longitud de clave y utilización de AES internamente en vez de RC4 como TKIP).
Bueno, pues dos investigadores de universidades japonesas (Hiroshima y Kobeshi), han descubierto otra manera de llevarse por delante el ya tambaleante WPA. El ataque anterior (Beck-Tews) se basaba en que podías descifrar texto de un paquete y falsificarlo siempre y cuando la implementación de WPA soportara 802.11e (Capacidades QoS). El que plantean los japoneses Toshihiro Ohigashi y Masakatu Morii (espero que a ellos les cueste lo mismo escribir mi nombre que a mí los suyos), permite romper el WPA-TKIP sin estas restricciones. La buena noticia es que el ataque es detectable por el usuario atacado mientras se intenta hacer el man-in-the-middle, puesto que en todo ese rato dicho usuario pierde la conectividad con el resto de la red. El ataque de Beck-Tews demoraba al menos 15 minutos en llevarse a cabo. Sin embargo, en el caso de los japoneses, en el mejor de los casos se tarda 1 minuto (dicha latencia puede achacarse a cualquier problema de red por parte de los usuarios, lo cuál otorga más probabilidades de pasar desapercibido).
El paper de cómo se lleva a cabo el ataque lo podéis descargar de aquí. He podido comprobar que es bastante denso de entender, aunque principalmente lo que dicen es que aplican el ataque Beck-Tews y una serie de inteligentes mecanismos para acelerar el tiempo de ataque de Man-in-the-Middle, posibilitando crackear WPA-TKIP sin el requisito de que soporte QoS según el estándar 802.11e.
¿Qué hacer entonces con las redes wifi?
Bueno, visto que WEP murió hace tiempo y que WPA está cada vez más perdido, la única solución wireless compatible para garantizar la confidencialidad de nuestras conexiones parece ser que es WPA2 o WPA en la modalidad EAP-PEAP-TLS (mediante utilización de certificados)
Como comentamos en el post del año pasado no creo que sea una mala recomendación el encapsulamiento del tráfico de red inalámbrico mediante VPNs convencionales como pueden ser IPSEC o SSL (con la implementación de OpenVPN por ejemplo).
13 comments :
@Lorenzo, hoy hablamos de lo mismo....;)
http://elladodelmal.blogspot.com/2009/09/el-minuto-de-la-wifi.html
¿Crackeado?
Estaba esperando ver cómo publicabais la noticia y me ha defraudado porque tiene el mismo tono amarillista y falto de información que en el resto del mundo.
Por hacer un resumen de lo que he visto: el ataque solo puede producir una denegación de servicio entre un AP y un cliente que no se veían previamente!!!!
No permite descifrar paquetes de datos (solo paquetes ARP), no permite bloquear conexiones si el cliente ve el AP, no permite obtener la clave para utilizar la conexión, ni siquiera permite ver la respuesta al paquete inyectado.
Así que me pregunto ¿crackeado? ¿Qué significa crackeado? ¿Hay alguna razón objetiva para no utilizar WPA/TKIP? He pedido ya en algún otro blog que se rectifiquen los artículos para que la gente que no lee los comentarios esté más informada. También lo pido modestamente aquí.
@Maligno -> <broma> es que ví en tu Twitter que estabas pensando en escribir de ello y te plagié... </broma>
@KNO-> este ataque es una evolución del anterior de Beck-Tews para efectuarlo en menos tiempo y en todas las implementaciones de WPA/TKIP. Como bien apuntas no es el mismo nivel de compromiso que presenta por ejemplo WEP. Es un tocado pero no hundido...
Sin embargo, y como creo que saber anticiparse es una de las máximas del mundo de la seguridad (y creo que en la vida en general) recomendamos otras medidas que de momento no tenemos referencias de que presenten compromisos, como solución total. Gracias por tu crítica igualmente...
@KNO, creo que tu postura es, tal vez, algo banderiza. Es cierto que el ataque (este y el anterior) son muy 'de laboratorio' y con una repercusión limitada, pero también así empezó el affaire MD5 cuando empezaron los primeros pappers sobre colisiones, y no falto quien tachó esos pappers de 'alarmistas' y luego, según evolucionó la técnica, todos sabemos lo que pasó. Lo cierto es que a WPA se le están empezando a encontrar 'hilos' y no tardara en deshilvanarse el vestido. En SbD siempre somos extremadamente cuidadosos a la hora de referenciar noticias / pappers, por ejemplo, cuando mucha gente caía presa del pánico con el supuesto reciente exploit del SSH (a mi me llegó hasta un mail de mi ISP pidiendo que actualizara), nosotros aplicamos la prudencia, y al final nos alegramos porque todo aquello fue un hoax. Un saludo y gracias por tu comentario
@KNO menudo tono utilizas, ¿eres un poco sobradete no?
Besitos
"espero que a ellos les cueste lo mismo escribir mi nombre que a mí los suyos"
Jajajaja, buena esa Lorenzo
Bueno, no es un ataque definitivo, y además este paper añade poco a lo ya existente, pero coincido en que es un paso más y un incentivo para usar WPA2/AES.
Saludos Malignos!
Exacto, no hace falta irse a EAP/PEAP/EAP-TLS/EAP-TTLS/PONGA-AQUÍ-SU-SABOR-FAVORITO porque entonces ¿qué sería de los usuarios caseros?
AES y punto :-)
Por cierto ¿Alguien ha esnifado tráfico PEAP? No acabo de entender (técnicamente sí...) por qué puedo ver en claro DOMINIO\usuario cuando el AP manda un Request Identity. ¿Sabéis si se arregla con EAP-TLS o EAP-TTLS? Me interesa sobretodo TTLS, que no requiere certificado en el cliente :-)
@Pj, pues no sabía yo que en el request indentity se veía en claro el usuario. ¿Estás con PEAP-MSCHAPv2? o ¿PEAP-TLS?.
Se supone que PEAP-TLS es similar en comportamiento al EAP-TTLS aunque incompatibles entre ellos. Voy a darle un vistazo, que parece interesante eso...
Saludos Malignos!
@Maligno
Hola, pues si no me equivoco (no soy un super-experto en el tema, fue una sorpresa para mi) era PEAP-MSCHAPv2.
No tengo ahora a mano los ficheros pcap pero sí una captura de pantalla del paquete en el Wireshark. Dentro de 802.1X Authentication hay:
Version: 1
Type: EAP Packet (0)
Length: 17
- Extensible Authentication Protocol (lo que viene abajo va dentro de esto)
Code: Response (2) <-- 1 si fuera Request
Id: 1
Length: 17
Type: Identity [RFC3748] (1)
Identity (12 bytes): DOMINIO\usuario
Y en el RFC de EAP (3748), sección 5.1 (Identity) dice:
Identity Requests and Responses are sent in cleartext, so an attacker may snoop on the identity, or even modify or spoof identity exchanges. To address these threats, it is preferable for an EAP method to include an identity exchange that supports per-packet authentication, integrity and replay protection, and confidentiality.
Lo del RFC no lo había mirado hasta ahora... 0:-)
Por cierto, todo esto desde fuera de la red. No disponía ni de credenciales para conectarme a ella (y para los quisquillosos, sí, era todo legal y hasta me pagaron por ello XDDDD)
@Pj, EAP es en texto claro sí, pero se supone que PEAP es Protected EAP o también conocida como TLS-EAP, es decir, que primero hay un tunel SSL antes de comenzar el EAP. ¿No tendrías un EAP-MSCHAPv2?
Saludos1
Juraría que era PEAP. Alguna vez, posterior a este análisis, he visto configurar una máquina cliente para conectar a la red y, eso, que juraría que era PEAP. De todas maneras el próximo martes saldremos de dudas, que me pasaré por allí.
Pero ahora estoy leyendo esto: http://www.ciscopress.com/articles/article.asp?p=369223&seqNum=2 y por propia definición de PEAP, no puede ser este.
Con lo que seguramente fuera EAP... Oh, espera: Mientras escribo este comentario sigo leyendo y he encontrado algo tal que así:
PEAPv0/EAP-MSCHAPv2 is the technical term for what people most commonly refer to as "PEAP". Whenever the word PEAP is used, it almost always refers to this form of PEAP since most people have no idea there are so many flavors of PEAP. Behind EAP-TLS, PEAPv0/EAP-MSCHAPv2 is the second most widely supported EAP standard in the world.
Sacado de: http://en.wikipedia.org/wiki/Extensible_Authentication_Protocol#PEAPv0.2FEAP-MSCHAPv2
¡Por lo que parece que he cometido un "common mistake" de esos! Eso no quita que, para lo que yo me encontré, la denominación PEAP-MsCHAPv2 sea incorrecta.
P.D.: (del mismo enlace) "Microsoft also only supports PEAPv0 and doesn’t support PEAPv1, so they simply call PEAPv0 PEAP without the v0 or v1 designator." Los clientes obviamente eran Windows. Estos de Spectra... guiño guiño guiño carita sonriente :-P
Saludos!
Publicar un comentario