KRACK – Análisis de la vulnerabilidad del protocolo WPA/2

Buenas a todos! La motivación de esta entrada es el gran revuelo que se está produciendo estos días a causa de la famosa vulnerabilidad del sistema de protección de redes inalámbricas más extendido y que hasta ahora no parecía tener fallas, WPA2.

Por fallas, entenderse que el protocolo se había demostrado matemáticamente seguro, sobre todo en las implementaciones que utilizan CCMP como protocolo de cifrado (frente al antiguo TKIP de WPA). Las redes inalámbricas protegidas con WPA2 han podido ser vulneradas a través de otros protocolos sobre la misma red, como los ataques a WPS, o mediante la captura del handshake, a partir del cual podemos adivinar (que no descifrar) mediante fuerza bruta la misma clave de conexión a la red inalámbrica.

Ha habido un grandísimo revuelo al extenderse la noticia de que el protocolo WPA2 ha sido «roto». Como siempre, el sensacionalismo ha ganado la batalla a la sensatez o a informarse de forma adecuada. Como opinión personal… ¿¿tanto cuesta echarle un ojo a la web oficial antes de sacar artículos?? Ya no digo el paper, para lo cual entiendo que se necesite tener una idea técnica del asunto, pero en la misma página web oficial del ataque se ofrece una descripción del mismo por el mismo autor, así como un FAQ que aclara el alcance del mismo.

Dicho esto, procedo a describir unos cuantos puntos acerca del funcionamiento del ataque a partir de la información publicada en el paper (que tomo como referencia y fuente de toda la información) y como clarificación ante la histeria que por desgracia se ha creado. Explicaré los ataques que más repercusión y gravedad implican: el ataque de reinstalación de claves en 4-way handshake y el ataque de reinstalación de clave de grupo. Otros ataques descritos en el paper, pero que no trataremos aquí por considerarlos (personalmente) ataques a protocolos mucho menos conocidos, son el ataque sobre PeerKey Handshake y sobre Fast BSS Transition (FT) Handshake.

¿Qué es eso del 4-way handshake?

El 4-way handshake, que podríamos traducir de alguna manera como «saludo a cuatro pasos», es una de las fases por las que pasan el punto de acceso y el cliente a la hora de negociar la conexión. Tras la autenticación (que en WPA/2 es OPEN, en herencia a WEP) y la asociación con el punto de acceso, se produce este handshake, paso en el que realizamos la «verdadera» autenticación con el sistema WPA/2 con la clave de nuestra red inalámbrica (también llamada clave precompartida o Pre-Shared Key (PSK), de ahí el nombre del protocolo WPA2-PSK).

A partir de la PSK se deriva una clave maestra o Pairwise Master Key, que normalmente es simplemente la PSK pasada por un algoritmo hash (SHA1) en redes personales. Esto se realiza de forma interna tanto en el AP como en el cliente, que ya conocen la PSK. La comunicación entre cliente y AP, por tanto, depende de que ambos conozcan la clave PSK (de ahí el funcionamiento de las arquitecturas de clave precompartida; si no conoces la clave, no puedes conectarte con el punto de acceso).

El objetivo del 4-way handshake es la negociación de una Pairwise Transient Key (PTK) o clave de sesión. La existencia de la clave de sesión es lo que nos garantiza que el resto de clientes conectados al punto de acceso inalámbrico no serán capaces de espiar nuestro tráfico, dado que es exclusiva entre nosotros y el punto de acceso y desconocida por el resto. A su vez, y sin entrar mucho en detalles, esta PTK se divide en la Key Confirmation Key (KCK), la Key Encryption Key (KEK) y la Temporary Key (TK). Las dos primeras se utilizan para proteger los mensajes del handshake, y la TK se usa posteriormente para proteger los paquetes normales garantizando una confidencialidad a nivel de datos. Esta clave de sesión se negocia en cuatro pasos, de ahí el nombre del proceso.

 

Esquema simplificado del 4-way handshake de WPA (Wikipedia)

Los cuatro pasos podríamos resumirlos de la siguiente manera:

  1. El punto de acceso le envía al cliente un valor arbitrario al cliente. Este valor pseudoaleatorio se suele llamar nonce.
  2. El cliente ahora es capaz de derivar la PTK concatenando el PMK, el nonce enviado por el AP, su propio nonce generado, la dirección MAC del AP y su propia dirección MAC. Esta concatenación se pasa por un algoritmo pseudoaleatorio. Ahora le envía al punto de acceso un mensaje incluyendo el nonce del cliente y un MIC (Message Integrity Check) que garantiza la integridad y autenticidad del mensaje.
  3. El punto de acceso ahora envía una Group Temporal Key (GTK), con la que se cifran los paquetes con destino múltiple en la red inalámbrica (broadcast y multicast), al cliente. En este punto, el cliente instala tanto la PTK como la GTK.
  4. EL cliente confirma la recepción de  la GTK al punto de acceso. Estos dos últimos pasos pueden repetirse posteriormente a lo largo de la conexión en caso de que la GTK cambie, cosa que suele hacer periódicamente.

A partir de este punto, ambos extremos conocen las claves necesarias para proteger las comunicaciones tanto a nivel de sesión exclusiva del cliente con la PTK como en los mensajes multidestino con la GTK. Este establecimiento de claves, como veremos a continuación, ha sido declarado vulnerable en el tercer paso, dando lugar al ataque de reinstalación de claves.

Por último, a lo largo de la conexión entre cliente y AP la GTK podría cambiar, como se ha comentado un poco más arriba. Para ello, el AP comienza un proceso llamado Group Key Handshake, que simplemente envía un mensaje a todos los clientes con la nueva GTK y reinstala esta clave una vez todos los clientes contesten o bien simplemente tras enviarles la clave a todos, dependiendo de la implementación. Este otro handshake, a su vez, es vulnerable también a la reinstalación de claves, como se verá también más adelante.

Si tan seguro es, ¿cómo se ha roto? Repetición del mensaje 3 del handshake

Lo primero es que la vulnerabilidad descubierta no se produce a nivel de implementación del protocolo, sino a nivel del protocolo en sí mismo. Al parecer, el protocolo no contempla la posibilidad de que el tercer mensaje del wpa-handshake pueda ser intencionalmente reenviado. Este reenvío provoca que las mismas claves vuelvan a instalarse en el cliente de nuevo, como hace normalmente después del tercer paso del handshake. Esto provoca que los números de secuencia o vectores de inicialización (IV) de los paquetes se reinicien, y por tanto, que WPA comience a utilizar keystreams (cadenas de caracteres generadas con la clave de cifrado que, combinadas con texto plano, resultan en el texto cifrado) que ya ha utilizado anteriormente para cifrar los paquetes.Esto se debe a que está utilizando la misma clave de sesión y el mismo número de secuencia o vector de inicialización para crear este keystream.

 

Proceso ampliado de intercambio de mensajes en la conexión a WPA, incluyendo el 4-way handshake (verde) y el tercer mensaje que puede reenviarse (rojo) (Paper original)

En caso de que los paquetes cifrados con el mismo keystream Para hacernos una idea, la repetición de keystreams iguales para cifrar paquetes es una de las razones por las que WEP fue considerado muy inseguro, permitiendo la recogida de una cantidad de vectores de inicialización repetidos suficientes para realizar un ataque estadístico contra la clave de cifrado.

Ataque al 4-way handshake – Reinstalación de claves

El ataque teórico que se ha descubierto para poder explotar este tipo de vulnerabilidad es el ataque de reinstalación de claves. En esencia, este ataque repite como hemos visto anteriormente el tercer mensaje del 4-way handshake de WPA hacia el cliente, de manera que éste vuelve a intalar estas claves y comienza a partir de ese momento a utilizar vectores de inicialización ya utilizados.

El primer obstáculo al ataque, como se describe en el paper, es que no todos los dispositivos implementan el protocolo de la misma manera. Por ejemplo, los dispositivos IOS y Windows no aceptan las retransmisiones del tercer mensaje, de manera que NO cumplen el estándar WPA tal y como se establece de forma oficial (esta vez por suerte). De todas formas, son vulnerables al siguiente ataque que describiremos más abajo (ataque a la clave de grupo).

El segundo obstáculo es que el atacante debe colocarse en posición de man in the middle (MiTM) entre el cliente y el punto de acceso. Dado que no es posible, como bien se dice en el paper, hacer esto con un rogue AP con una dirección MAC diferente, se debe colocar este punto de acceso falso con la misma dirección MAC que el verdadero y en un canal diferente, otra forma de realizar este tipo de ataques. La razón de esto es que la PTK depende de la dirección MAC del AP; si es diferente, no podremos negociar exactamente la misma. Hecho esto, ya podemos recibir todos los paquetes que intercambien y reenviarlos a sus legítimos.

Otro obstáculo es que en ciertas implementaciones solo se aceptarán retransmisiones del tercer paquete que estén cifradas por la PTK inicialmente instalada, ignorando la retransmisión en texto plano, mientras que otras sí que aceptaran la retransmisión sin cifrar. En caso de que acepte retransmisiones no cifradas, el ataque resulta más o menos trivial. Primero se intercepta el cuarto mensaje del handshake que va de cliente a AP impidiendo que llegue al mismo. Podemos ahora retransmitir el tercer mensaje un número arbitrario de veces para realizar el ataque.

Una vez sea exitoso, enviaremos el cuarto mensaje que habíamos guardado al AP para que termine por su lado la instalación de las claves. Existe un replay counter que incrementa cada vez que se realiza la retransmisión, pero el AP en muchas implementaciones instala las claves sin poner problemas por que este número no coincida con la realidad. Otra razón por la que usar este antiguo paquete capturado es que tras la primera instalación de la PTK el cliente envia este paso siempre de forma cifrada con la misma, pero el AP no la ha instalado aún, así que la rechazaría de no estar en texto plano.

 

Esquema del ataque cuando el cliente acepta la retramisión en texto plano (Paper)

En caso de que el cliente solamente admita el reenvío del tercer paso con el cifrado de la PTK, esto se complica. Debe hacerse un bypass de esta protección. En el paper se describen varios métodos. Por ejemplo, en Android se aprovecha de una condición de carrera, en la que el controlador de red del cliente recibe el tercer mensaje y su retransmisión de forma muy rápida, de forma que acepta ambos antes de que la CPU envíe la orden de instalar las claves, tras lo cual no readmitiría más retransmisiones sin cifrar. Así podemos «colar» una o varias retransmisiones antes de que se instalen las claves, obteniendo a su vez varios cuartos mensajes del handshake como respuesta.

Esquema del ataque cuando el cliente no acepta la retramisión en texto plano (1) (Paper)

Otro bypass descrito que funciona contra OpenBSD, OSX y macOS espera a que se realice en algún momento un segundo handshake de refresco de la PTK, que ocurre de vez en cuando. Cuando el atacante detecta que se envía el tercer paso (por su longitud y destino, dado que en este punto todo está cifrado) lo guarda y espera a la retransmisión legítima por parte del AP. Una vez la recibe, reenvía ambas seguidas, de forma que se realiza la instalación de las claves dos veces.

Esquema del ataque cuando el cliente no acepta la retramisión en texto plano (2) (Paper)

Ataque al handshake de clave de grupo

No para aquí el ataque. Además de poder atacar al 4-way handshake para poder realizar una reinstalación de las claves, podemos realizar este mismo proceso (o muy parecido) contra las negociaciones de clave de grupo o GTK que se realizan de manera más o menos periódica. Recordemos que la clave de grupo se la que permite realizar el cifrado sobre paquetes broadcast y multicast. La consecuencia de este otro ataque es que el atacante podrá realizar reenvío de paquetes broadcast/multicast, que puede no parecer tan grave como lo anterior (donde podemos conocer el contenido del tráfico del cliente), pero sigue siendo un fallo serio del protocolo.

La renovación se realiza cuando el punto de acceso envía a los clientes un mensaje indicando la nueva GTK. Los clientes a su vez envían un mensaje de confirmación al AP. La clave queda instalada en el cliente una vez recibida y antes de enviar la confirmación, y en el punto de acceso al recibir la confirmación de todos los clientes o bien al enviar las notificaciones, según implementación. El estándar indica que debe esperar a que todos hayan respondido. Se ha comprobado que, exactamente igual que en el caso anterior, el cliente reinicia la numeración de los vectores de inicialización al reinstalar de esta forma la GTK.

En caso de que realice la instalación de forma inmediata al enviar notificaciones, el AP envía la petición de actualizar la GTK y el cliente instalará dicha clave. El atacante bloqueará la respuesta de confirmación del cliente hacia el punto de acceso y esperará a que se reenvíe la petición desde el mismo. Esperará a que se realice el reenvío de la petición para renovar la clave por parte del punto de acceso hacia el cliente, y la bloqueará también. En este punto el atacante esperará a que se realice por parte del AP el envío de un paquete broadcast. Dejará pasar este paquete, y acto seguido enviará la retransmisión que ha capturado hacia el cliente, que realizará la reinstalación de las claves, nuestro objetivo. En este punto, podemos volver a enviar el paquete broadcast de nuevo, dado que el replay counter es reiniciado tras la instalación de la GTK.

Por esto mismo es esencial enviar al cliente la retransmisión del mensaje de actualización después de realizar el reenvío del paquete broadcast, dado que el paquete de retransmisión de la GTK contiene el replay counter actual, que será reiniciado tras la reinstalación de la clave y permite abusar del reenvío del paquete broadcast.

Descripción del ataque a la clave de grupo cuando la clave se instala de forma inmediata en el AP (paper)

Si el AP instala la nueva GTK cuando ha recibido todas las confirmaciones de los clientes, esto se complica un poco. En este caso, el atacante vuelve a bloquear la respuesta de confirmación de cliente, de manera que el punto de acceso vuelve a enviar la actualización de la clave. En este punto, el atacante bloquea de nuevo esta retransmisión y envía al AP la confirmación del cliente que había capturado, de manera que el AP ya puede instalarse la nueva GTK. Hecho esto, esperará a que el AP envíe un mensaje broadcast cifrado con esta nueva clave, que dejará pasar al cliente. Tras esto, enviará al cliente la retransmisión de la petición de actualización que había capturado anteriormente, provocando la actualización de la GTK en cliente y la retransmisión del paquete broadcast.

Descripción del ataque a la clave de grupo cuando la clave se instala de forma retardada en el AP (paper)

Consecuencias de estos ataques

Tanto en el ataque sobre el 4-way handshake como el ataque contra el handshake de clave de grupo, las consecuencias dependen del protocolo de encriptación utilizado en la red. Potencialmente, se permite retransmisión, descifrado y falsificación de paquetes, pero solamente en una dirección, dependiendo de el extremo que ataquemos. Esto es debido a que normalmente en los ataques descritos la víctima es el cliente, y es de éste quien podremos descifrar totalmente los paquetes mediante la reutilización de los nonces al reinstalar las claves, habiendo campos diferentes como el Message Integrity Code (MIC) que varían en el cliente y el AP.

En el ataque sobre 4-way handshake, podemos en caso tanto de TKIP (más utilizado en WPA), CCMP (utilizado casi siempre en WPA2) y GCMP (de implantación en protocolos futuros) retransmitir paquetes desde el AP al cliente y descifrar paquetes del cliente hacia el AP. En caso de TKIP podemos además falsificar paquetes desde el cliente hacia el AP, y en GCMP podemos falsificar en ambas direcciones.

En el caso del ataque sobre el handshake de grupo, en cualquiera de ellos, como hemos visto, podremos retransmitir paquetes broadcast/multicast desde el AP hacia el cliente.

Tabla sobre las consecuencias de los ataques sobre TKIP, CCMP y GCMP (paper)

Por nombrar algunos potenciales ataques, el atacante podría falsificar tráfico HTTP enviado desde el cliente, inyectando código malicioso. Podría tomar el control de un protocolo que actúe como broadcast, como implementaciones de NTP, provocando que los clientes se queden «atascados» en la misma hora. Podríamos espiar las credenciales enviadas desde el cliente hacia un servidor FTP o cualquier otro protocolo desprotegido. Las posibilidades son casi infinitas.

Vulnerabilidad de la clave de encriptación a todo ceros

En el paper también se nombra un caso especial de la vulnerabilidad sobre wpa_supplicant, una herramienta utilizada ampliamente por sistemas Linux para interactuar como cliente en una red inalámbrica WPA/2. En las versiones 2.3 hacia atrás, el ataque funciona sin otros efectos secundarios. En las versiones 2.4 y 2.5, adicionalmente, tras una retransmisión del tercer mensaje del 4-way handshake, misteriosamente se instala una clave de encriptación TK compuesta de todo ceros. Al parecer, se debe a que indirectamente se sugiere que la TK debe borrarse de memoria una vez instalada. La versión 2.6 corrige este bug, pero al no considerarse crítico no se forzó sobre versiones anteriores. Independientemente de esto, wpa_supplicant es igualmente vulnerable a ataques sobre el handshake de clave de grupo.

Android, que utiliza una versión ligeramente modificada de esta herramienta, es también vulnerable en su versión 6.0 y en Android Wear 2.0.

Contramedidas

Las contramedidas contra este ataque no pueden ser mas simples. Parchea tus clientes y puntos de acceso (sobre todo los primeros) en cuanto esté disponible el parche. No es necesaria ni posible otra contramedida, dado que hasta que la herramienta nos e parchee por parte del fabricante o proveedor de software seguimos siendo vulnerables (a no ser que no conectarse a ninguna red pueda considerarse una contramedida, que no).

Por parte del fabricante, el «remiendo» es simple. Se debería verificar que si se está tratando de reinstalar una clave que ya esté actualmente en uso. Si lo está, no se deben resetear los nonces y replay counters para evitar la repetición de keystreams y provocar la vulnerabilidad. Otra solución sería diretamente impedir que se reinstalen claves, permitiendo solamente la instalación de las mismas la primera vez que se reciban.

¿¿Es mi dispositivo vulnerable??

En la duda, piensa que sí. Se ha dicho anteriormente que los dispositivos con iOS y Windows no son vulnerables, por su implementación, al ataque sobre el 4-way handshake, pero siguen siéndolo sobre el ataque sobre la clave de grupo. Esto es lo que he ido viendo acerca de los parches en diferentes distribuciones de software a día 19 de octubre (comprobadlo vosotros mismos, sobre todo en cuanto a vuestros dispositivos concretos):

  • Microsoft parcheó la vulnerabilidad en un parche del día 16 de octubre.
  • En Android, Google pretende instalar el parche en la actualización del 6 de noviembre. En tu móvil en concreto dependerá de que el fabricante distribuya esta actualización.
  • En dispositivos iOS, se está trabajando en el parche.
  • En sistemas Linux, el parche para wpa_supplicant está ya ampliamente disponible.
  • En sistemas OpenBSD, esto está solucionado desde julio. Wow.

Vuelvo a decir que, por si las moscas, actualizáos vosotros en función del dispositivo o sistema que poseéis y que no queráis que sea vulnerable. Sobre todo en cuanto a fabricantes de puntos de acceso, en los que tendremos que confiar a la hora de que saquen el firmware que soluciona la vulnerabilidad (y sabemos que las cosas de palacio van despacio).

Y hasta aquí la entrada de hoy, chicos. Espero de verdad que os sirva para entender un poco mejor el ataque (aunque al final me ha quedado un tochazo igualmente) y os ayude a superar otro fenómeno de histeria colectiva. KRACK es, definitivamente, un trabajo de investigación enorme y presenta unas vulnerabilidades graves. Pero todavía intento seguir la lógica de las recomendaciones de ciertas publicaiones que insisten en que cambiemos la contraseña del WIFI porque WPA2 se ha roto y prácticamente hay que volver al cable. De nuevo, os animo a leer el paper. Un saludo!!

4 comentarios en «KRACK – Análisis de la vulnerabilidad del protocolo WPA/2»

  1. Buena entrada, arrojando un poco de calma y de luz sobre KRACK, aunque como bien dices el paper ya explica con detalle, y lo que es mejor, el autor (Mathy Vanhoef‏) creó una web con unas FAQ de fácil lectura https://www.krackattacks.com/

    En twitter, hay quien ha llegado a acusar a KRACK como un fraude debido a la diferencia que hay entre la expectación exagerada que se ha creado con la vulnerabilidad y las posibilidades de aplicación práctica… incluyendo retos a demostrar las posibilidades prácticas de explotación con bitcoins de por medio: https://twitter.com/Ben_SniffWiFi/status/920715536123641856

    Un tema de lo más interesante.

    1. Buenas Leandro, gracias por el comentario! En la misma entrada referencio a esa misma página del autor 🙂 Por otra parte, considerar un fraude a KRACK sería disparatado, dado que desde el primer momento de la publicación ha estado el paper disponible. Han sido los medios que han tratado la noticia como han querido, por desgracia. Un saludo!

  2. Un tema bastante curioso y sin duda interesante de saber y estar al tanto sobre el, no estoy muy metida en este mundillo de bytes, pero siempre me gusta estar informada, aprendiendo cada día más cosas, gracias.

Los comentarios están cerrados.