La realidad de KRACK: la vulnerabilidad de las redes WiFi WPA2

A principios de esta semana saltaba la noticia como una bomba: el protocolo utilizado en la práctica totalidad de conexiones WiFi de todo el mundo, WPA2, había sido vulnerado.

En las primeras horas, como por desgracia es cada vez más habitual con cualquier tipo de noticia, el sensacionalismo se apoderó de las redes sociales y de muchas cabeceras de diarios digitales: estamos en peligro.

<--more-->

Pero realmente ¿en qué consiste este llamado “KRACK”? ¿es realmente tan preocupante como parece?
 

¿Qué es KRACK?

 
En realidad, KRACK hace referencia a un artículo académico llamado “Key Resinstallation Attacks: Forcing Nonce Reuse in WPA2” publicado por Mathy Vanhoef, un investigador de la Universidad Católica de Lovaina (KU Leuven) que será presentado oficialmente durante la Computer and Communications Security (CCS) el 1 de Noviembre. En este artículo se expone un conjunto de métodos para vulnerar la manera en que un punto de acceso y un cliente intercambian la información inicial al conectarse a una red WiFi. Mediante esta vulnerabilidad un atacante podría “engañar” al cliente para que reenviara la información de asociación (handshake) a dicho punto a fin de capturar su tráfico.
 

¿Cómo funciona KRACK?

 
Aunque quizá resulte demasiado técnico, voy a intentar explicar a grandes rasgos, pero de forma clara cómo se ejecuta este ataque:

KRACK Logo por www.krackattacks.com bajo licencia CC 4.0 BY

Al intentar conectarse a red WiFi protegida con WPA2 (que recordemos, tiene ya 14 años), el cliente intercambia con el punto de acceso (AP) un proceso de asociación de 4 mensajes (conocido como 4-way handshake), de esta manera ambos extremos negocian una clave de cifrado para las comunicaciones posteriores. Esta clave se instala en el cliente al recibir el tercer mensaje del proceso, pero el protocolo WPA2 contempla que en caso en el que esos mensajes se pierdan, el AP volverá a retransmitir el mensaje número 3 si no recibe una respuesta adecuada del cliente, y por tanto, el cliente puede recibir el mensaje 3 varias veces. Cada vez que recibe este mensaje, volverá a instalar la misma clave de cifrado reiniciado a su valor inicial parámetros como el número incremental de paquetes transmitidos (nonce) y el número de paquetes recibidos (replay counter) usados por el protocolo de cifrado. Es ese momento el que el atacante puede forzar dichos reinicios recolectando y re-emitiendo el tercer mensaje de la asociación de 4 vías para intentar que el cliente utilice una clave de cifrado ya conocida y, por tanto, descifrar la comunicación.
 

¿Es tan grave como parece?

 
El problema es grave principalmente, por dos motivos: el primero, no se trata de un error de implementación de ningún fabricante en concreto, se trata de un agujero de seguridad del propio protocolo. Y el segundo, es porque la vulnerabilidad se encuentra en el cliente de la conexión, es decir, en los dispositivos (ordenadores, smartphones, tablets, SmartTV, etc) que se asocian a una red WiFi, y a priori, todos los sistemas operativos presentan la vulnerabilidad, y necesitan ser parcheados.

Por ejemplo, en la primera prueba de concepto presentada, que ya tiene unos meses de antigüedad, se hace un test y se expone que todos los sistemas Android a partir de la versión 6.0 son especialmente vulnerables por cómo gestionan los reinicios de la clave de cifrado. Por lo tanto, nos tememos que muchos equipos con sistemas operativos antiguos, smartphones, dispositivos de Internet de las Cosas (IoT), etc. ya no tienen soporte por parte de los fabricantes y, por tanto, no recibirán el parche necesario para que sean seguros. De hecho, mucha electrónica de consumo no se llega a actualizar nunca desde que sale de fábrica.

Llegados a este escenario, un atacante en posesión de las claves con la que la comunicación entre cliente y punto de acceso se cifra, podría capturar el tráfico que enviemos y, potencialmente, robar información que estemos transfiriendo en ese momento. Incluso, si nuestra conexión WiFi utiliza cifrado TKIP en lugar de AES, el atacante podría llegar a inyectar tráfico con paquetes alterados realizando un ataque man-in-the-middle, por ejemplo, con páginas web modificadas, archivos infectados, etc.
 

La realidad del alcance de KRACK

 
Esto nos lleva a hacer varias consideraciones para que, fuera del sensacionalismo y la desinformación inicial, seamos consientes del alcance real de esta vulnerabilidad.

En primer lugar, la vulnerabilidad, todavía no ha sido explotada más allá de la prueba de concepto presentada, y por lo tanto, no se conoce aún ningún caso real de robo de información mediante esta técnica, y todavía hay tiempo para que los fabricantes apliquen sus parches hasta que se publique la forma de llevar a cabo el ataque.

Se trata de una vulnerabilidad del cliente, así que, no podemos reconfigurar o cambiar la clave de nuestro router o AP para protegernos. Por supuesto, en ningún caso es recomendable, como se ha dicho, cambiar el protocolo de validación de nuestra red WiFi por protocolos obsoletos que han demostrado ser débiles en sí mismos, como WPA y, sobre todo, WEP. Sí podríamos, en cambio, cambiar el cifrado de nuestra conexión a AES si no lo fuera ya para evitar la inyección de tráfico.

La vulnerabilidad no es explotable en remoto, es decir, el atacante tendría que estar físicamente dentro del rango de cobertura de la red WiFi para poder llevar a cabo el ataque, lo cual limita mucho sus capacidades.

Y más importante aún, los protocolos cifrados de extremo a extremo NO son vulnerables. Por ejemplo, conexiones cifradas como HTTPS, SSH, SFTP, IMAPS o conexiones VPN no son vulnerables a este ataque ya que el atacante, aun capturando el tráfico de estas comunicaciones, sólo encontrará tráfico cifrado que no podrá descifrar. Cabe destacar que, en algunos casos concretos, utilizando otras técnicas unidas a esta misma, sí es posible conseguir que en algunas conexiones cifradas, pero mal implementadas, la conexión se pueda forzar a realizarse sin cifrado SSL mediante HTTP y no HTTPS. Por eso, siempre es importante cerciorarnos de estar utilizando protocolos seguros en nuestras conexiones.

Y por último, parece obvio, pero no está de más recalcar que los sistemas conectados por cable de red, no son vulnerables. Esto excluye a todo el ámbito de servidores y data centers de la vulnerabilidad.

Si bien es cierto que, como hemos dicho, la vulnerabilidad es del cliente y por tanto, es quien debe recibir una actualización de seguridad para dejar de estar expuesto, algunos fabricantes de equipamiento de red han publicado parches de seguridad que sí son capaces de mitigar este ataque. Y de nuevo, volvemos a tener que preocuparnos de los dispositivos antiguos y sin soporte por parte de fabricantes, como por ejemplo los routers domésticos de grandes operadoras, que tardarán en recibir estos parches, si es que lo acaban haciendo.

Según anunció Mathy Vanhoef, desde el pasado julio ha ido contactando diversos fabricantes para advertir de la vulnerabilidad, la forma de corregirlo y la fecha en que se se haría público. Es por eso que, ejemplificando sobre los equipos con capacidades WiFi que utiliza Sarenet, ya han recibido parches Mikrotik, que publicó a principios de Octubre sus actualizaciones, y Ubiquiti hizo lo propio apenas 3 horas después de hacerse público KRACK. Podéis consultar una lista de fabricantes y sus reacciones en el siguiente enlace: https://www.bleepingcomputer.com/news/security/list-of-firmware-and-driver-updates-for-krack-wpa2-vulnerability/

No obstante, es muy importante que actualicemos todos nuestros dispositivos en cuanto su fabricante publique las actualizaciones.

A modo de anécdota, el propio Vanhoef cuenta como OpenBSD parcheó “de manera silenciosa” sus sistemas mucho antes de la ventana establecida para el resto de fabricantes, lo que podría haber ocasionado que un atacante fuera consciente de esta vulnerabilidad y explotarla antes de que los demás fabricantes pudieran subsanarla y, por tanto, en el futuro OpenBSD será avisada mucho más cerca del deadline que las demás.

En resumen, la lección que podemos extraer de todo este asunto, no es de extrañar que sea la misma de siempre: la mejor estrategia de protección contra esta o cualquier otra vulnerabilidad futura siempre será contar con equipos profesionales y de calidad que estén actualizados dentro de su ciclo vida útil y respaldados por un soporte experto y diligente.

Contacta ahora con Sarenet