Comunicado Oficial - ¡Hackean el protocolo WPA2! Todas las redes WiFi en riesgo.
Introducción
Descubrimos debilidades serias en WPA2, un protocolo que asegura todas las redes Wi-Fi protegidas modernas. Un atacante dentro del alcance de la víctima puede explotar estas debilidades usando Key Reinstallation Attacks(KRACKs). Concretamente, los atacantes pueden usar esta nueva técnica de ataque para leer información que previamente se suponía que estaba cifrada de forma segura. Esto se puede abusar para robar información confidencial, como números de tarjetas de crédito, contraseñas, mensajes de chat, correos electrónicos, fotos, etc. El ataque funciona contra todas las redes Wi-Fi protegidas modernas . Dependiendo de la configuración de la red, también es posible inyectar y manipular datos. Por ejemplo, un atacante podría inyectar ransomware u otro malware en sitios web.
Las debilidades están en el estándar Wi-Fi en sí y no en productos individuales o implementaciones. Por lo tanto, es probable que se vea afectada cualquier implementación correcta de WPA2. Para evitar el ataque, los usuarios deben actualizar los productos afectados tan pronto como las actualizaciones de seguridad estén disponibles. Tenga en cuenta que si su dispositivo es compatible con Wi-Fi, lo más probable es que se vea afectado. Durante nuestra investigación inicial, descubrimos que Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys y otros, se ven afectados por alguna variante de los ataques. Para obtener más información sobre productos específicos, consulte la base de datos de CERT (Computer Emergency Response Team)/CC o comuníquese con su proveedor.
La investigación detrás del ataque se presentará en la conferencia sobre Seguridad Informática y comunicaciones (CCS) y en la conferencia Black Hat Europe.
Las debilidades están en el estándar Wi-Fi en sí y no en productos individuales o implementaciones. Por lo tanto, es probable que se vea afectada cualquier implementación correcta de WPA2. Para evitar el ataque, los usuarios deben actualizar los productos afectados tan pronto como las actualizaciones de seguridad estén disponibles. Tenga en cuenta que si su dispositivo es compatible con Wi-Fi, lo más probable es que se vea afectado. Durante nuestra investigación inicial, descubrimos que Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys y otros, se ven afectados por alguna variante de los ataques. Para obtener más información sobre productos específicos, consulte la base de datos de CERT (Computer Emergency Response Team)/CC o comuníquese con su proveedor.
La investigación detrás del ataque se presentará en la conferencia sobre Seguridad Informática y comunicaciones (CCS) y en la conferencia Black Hat Europe.
Demostración.
Cómo prueba de concepto, ejecutamos un ataque clave de reinstalación contra un teléfono inteligente Android. En esta demostración, el atacante puede descifrar todos los datos que transmite la víctima. Para un atacante, esto es fácil de lograr, porque nuestro ataque de reinstalación clave es excepcionalmente devastador contra Linux y Android 6.0 o superior. Esto se debe a que Android y Linux pueden engañarse para (re)instalar una clave de cifrado totalmente nula( ver más abajo para obtener más información ). Al atacar a otros dispositivos, es más difícil descifrar todos los paquetes, aunque se puede descifrar un gran número de paquetes. En cualquier caso, la siguiente demostración destaca el tipo de información que un atacante puede obtener al
realizar ataques de reinstalación de claves contra redes de Wi-Fi protegidas:
Nuestro ataque no se limita a recuperar credenciales de inicio de sesión (es decir, direcciones de correo electrónico y contraseñas). En general, cualquier dato o información que la víctima transmita puede descifrarse. Además, según el dispositivo que se utilice y la configuración de la red, también es posible descifrar los datos enviados a la víctima (por ejemplo, el contenido de un sitio web). Aunque los sitios web o las aplicaciones pueden usar HTTPS como una capa adicional de protección, le advertimos que esta protección extra puede (todavía) pasarse por alto en un número preocupante de situaciones. Por ejemplo, HTTPS se omitió anteriormente en el software de navegadores, en iOS y OS X de Apple, en aplicaciones de Android , en aplicaciones de Android nuevamente, en aplicaciones de respaldo e incluso en aplicaciones VPN.
Detalles
Nuestro ataque principal está en contra del protocolo de enlace (handshake) de 4 vías del protocolo WPA2. Este protocolo de enlace se ejecuta cuando un cliente desea unirse a una red Wi-Fi protegida, y se utiliza para confirmar que tanto el cliente como el punto de acceso poseen las credenciales correctas (por ejemplo, la contraseña precompartida de la red). Al mismo tiempo, el protocolo de enlace de 4 vías también negocia una nueva clave de cifrado que se utilizará para cifrar todo el tráfico subsiguiente. Actualmente, todas las redes Wi-Fi protegidas modernas utilizan el protocolo de enlace de 4 vías. Esto implica que todas estas redes se ven afectadas por (alguna variante de) nuestro ataque. Por ejemplo, el ataque funciona contra redes Wi-Fi personales y empresariales, contra el WPA anterior y el último estándar WPA2, e incluso contra redes que solo usan AES. Todos nuestros ataques contra WPA2 usan una técnica novedosa llamada ataque de reinstalación clave (KRACK):
Ataques clave de reinstalación: descripción de alto nivel
En un ataque de reinstalación de clave, el adversario engaña a una víctima para que vuelva a instalar una clave que ya está en uso. Esto se logra manipulando y reproduciendo mensajes criptográficos de comunicación . Cuando la víctima reinstala la clave, los parámetros asociados, como el número de paquete de transmisión incrementa y el número de paquete de recepción (es decir, el contador de reproducción) se restablecen a su valor inicial. Básicamente, para garantizar la seguridad, una clave solo debe instalarse y usarse una vez. Desafortunadamente, encontramos que esto no está garantizado por el protocolo WPA2. Al manipular los protocolos de enlace criptográficos, podemos abusar de esta debilidad en la práctica.
Ataques clave de reinstalación: ejemplo concreto contra el protocolo de enlace de 4 vías.
Como se describe en la introducción del documento de investigación, la idea detrás de un ataque clave de reinstalación se puede resumir de la siguiente manera. Cuando un cliente se une a una red, ejecuta el enlace de 4 vías para negociar una nueva clave de cifrado. Instalará esta clave después de recibir el mensaje 3 del protocolo de enlace de 4 vías. Una vez que se instala la clave, se usará para cifrar los marcos de datos normales utilizando un protocolo de encriptación. Sin embargo, como los mensajes se pueden perder o descartar, el Punto de acceso (AP) retransmitirá el mensaje 3 si no recibió una respuesta apropiada como acuse de recibo. Como resultado, el cliente puede recibir el mensaje 3 varias veces. Cada vez que recibe este mensaje, reinstalará la misma clave de cifrado y, por lo tanto, reiniciará el número de paquete de transmisión incremental y recibirá el contador de reproducción utilizado por el protocolo de cifrado. Mostramos que un atacante puede forzar estos restablecimientos recolectando y reproduciendo retransmisiones del mensaje 3 del protocolo de enlace de 4 vías. Al forzar la reutilización del nonce de esta manera, el protocolo de encriptación puede ser atacado, por ejemplo, los paquetes pueden ser reproducidos, descifrados y / o forjados. La misma técnica también se puede utilizar para atacar a la clave de grupo, PeerKey, TDLS, y rápido enlace de transición BSS.
Impacto practico
En nuestra opinión, el ataque más extendido y prácticamente impactante es el ataque de reinstalación clave contra el protocolo de enlace de 4 vías. Basamos este juicio en dos observaciones. Primero, durante nuestra propia investigación encontramos que la mayoría de los clientes se vieron afectados por ella. En segundo lugar, los adversarios pueden usar este ataque para descifrar los paquetes enviados por los clientes, lo que les permite interceptar información confidencial, como contraseñas o cookies. El descifrado de paquetes es posible porque un ataque de reinstalación de clave hace que los números de transmisión (a veces también denominados números de paquete o vectores de inicialización) se restablezcan a cero. Como resultado, se usa la misma clave de cifrado con valores nonce que ya se han usado en el pasado . A su vez, esto hace que todos los protocolos de encriptación de WPA2 reutilicen el flujo de claves al encriptar los paquetes. En caso de que un mensaje que reutilice el flujo de claves tenga contenido conocido, se vuelve trivial derivar el flujo de claves usado. Este flujo de claves se puede usar para descifrar mensajes con el mismo valor. Cuando no hay contenido conocido, es más difícil descifrar paquetes, aunque aún es posible en varios casos. En la práctica, encontrar paquetes con contenido conocido no es un problema, por lo que se debe suponer que cualquier paquete puede descifrarse.
La capacidad de descifrar paquetes puede usarse para descifrar paquetes TCP/SYN. Esto permite a un adversario obtener los números de secuencia TCP de una conexión y secuestrar las conexiones TCP. Como resultado, aunque se usa WPA2, el adversario ahora puede realizar uno de los ataques más comunes contra redes Wi-Fi abiertas: inyectar datos maliciosos en conexiones HTTP no cifradas. Por ejemplo, un atacante puede abusar de esto para inyectar ransomware o malware en sitios web que la víctima está visitando.
Si la víctima usa el protocolo de cifrado WPA-TKIP o GCMP, en lugar de AES-CCMP, el impacto es especialmente catastrófico. Contra estos protocolos de encriptación, la reutilización de nonce permite a un adversario no solo descifrar, sino también forjar e inyectar paquetes . Además, debido a que GCMP utiliza la misma clave de autenticación en ambas direcciones de comunicación, y esta clave se puede recuperar si los números se reutilizan, se ve especialmente afectada. Tenga en cuenta que la compatibilidad con GCMP se está actualizando con el nombre Wireless Gigabit (WiGig), y se espera que se adopte a un ritmo elevado en los próximos años.
La dirección en la que los paquetes pueden descifrarse (y posiblemente forjarse) depende del protocolo de enlace que se está atacando. Simplificado, al atacar el enlace de 4 vías, podemos descifrar (y forjar) los paquetes enviados por el cliente. Al atacar el protocolo de enlace de Fast BSS Transition (FT), podemos descifrar (y forjar) los paquetes enviados al cliente. Finalmente, la mayoría de nuestros ataques también permiten la reproducción de tramas unidifusión, difusión y multidifusión. Para más detalles, consulte la Sección 6 de nuestro trabajo de investigación .
Tenga en cuenta que nuestros ataques no recuperan la contraseña de la red Wi-Fi . Tampoco recuperan (ninguna parte de) la nueva clave de encriptación que se negocia durante el protocolo de enlace de 4 vías.
Android y Linux
Nuestro ataque es especialmente catastrófico contra la versión 2.4 y superior de wpa_supplicant, un cliente Wi-Fi comúnmente usado en Linux. Aquí, el cliente instalará una clave de cifrado totalmente cero en lugar de reinstalar la clave real. Esta vulnerabilidad parece ser causada por un comentario en el estándar Wi-Fi que sugiere borrar la clave de cifrado de la memoria una vez que se instaló por primera vez. Cuando el cliente recibe ahora un mensaje retransmitido 3 del protocolo de 4 vías, volverá a instalar la clave de cifrado ahora borrada, instalando efectivamente una clave de cero. Como Android usa wpa_supplicant, Android 6.0 y superior también contiene esta vulnerabilidad. Esto hace que sea trivial interceptar y manipular el tráfico enviado por estos dispositivos Linux y Android . Tenga en cuenta que actualmente el 41% de los dispositivos Android son vulnerables a esta variante excepcionalmente devastadora de nuestro ataque.
Asignados identificadores CVE
Se asignaron los siguientes identificadores y vulnerabilidades comunes (CVE, por sus siglas en inglés) para rastrear qué productos se ven afectados por instancias específicas de nuestro ataque de reinstalación clave:
* CVE-2017-13077 : Reinstalación de la clave de encriptación pairwise (PTK-TK) en el enlace de 4 vías.
* CVE-2017-13078 : Reinstalación de la clave de grupo (GTK) en el enlace de 4 vías.
* CVE-2017-13079 : Reinstalación de la clave del grupo de integridad (IGTK) en el enlace de 4 vías.
* CVE-2017-13080 : Reinstalación de la clave de grupo (GTK) en el protocolo de enlace de grupo.
* CVE-2017-13081 : Reinstalación de la clave de grupo de integridad (IGTK) en el protocolo de enlace de grupo.
* CVE-2017-13082 : aceptación de una solicitud de reasignación de transición rápida de BSS (FT) y reinstalación de la clave de cifrado por parejas (PTK-TK) mientras la procesa.
* CVE-2017-13084 : Reinstalación de la tecla STK en el protocolo de enlace PeerKey.
* CVE-2017-13086 : reinstalación de la clave de configuración de enlace directo Tunneled (TDLS) PeerKey (TPK) en el protocolo de enlace TDLS.
* CVE-2017-13087 : reinstalación de la clave de grupo (GTK) al procesar un marco de respuesta de modo de suspensión de gestión de red inalámbrica (WNM).
* CVE-2017-13088 : reinstalación de la clave de grupo de integridad (IGTK) al procesar un marco de respuesta de modo de suspensión de gestión de red inalámbrica (WNM).
Tenga en cuenta que cada identificador de CVE representa una instanciación específica de un ataque de reinstalación de clave. Esto significa que cada ID de CVE describe una vulnerabilidad de protocolo específica y, por lo tanto, muchos proveedores se ven afectados por cada ID de CVE individual . También puede leer la nota de vulnerabilidad VU#228519 de CERT/CC para obtener detalles adicionales sobre qué productos se sabe que están afectados.
* CVE-2017-13086 : reinstalación de la clave de configuración de enlace directo Tunneled (TDLS) PeerKey (TPK) en el protocolo de enlace TDLS.
* CVE-2017-13087 : reinstalación de la clave de grupo (GTK) al procesar un marco de respuesta de modo de suspensión de gestión de red inalámbrica (WNM).
* CVE-2017-13088 : reinstalación de la clave de grupo de integridad (IGTK) al procesar un marco de respuesta de modo de suspensión de gestión de red inalámbrica (WNM).
Tenga en cuenta que cada identificador de CVE representa una instanciación específica de un ataque de reinstalación de clave. Esto significa que cada ID de CVE describe una vulnerabilidad de protocolo específica y, por lo tanto, muchos proveedores se ven afectados por cada ID de CVE individual . También puede leer la nota de vulnerabilidad VU#228519 de CERT/CC para obtener detalles adicionales sobre qué productos se sabe que están afectados.
Herramientas
Hemos realizado secuencias de comandos para detectar si una implementación del protocolo de enlace de 4 vías, el protocolo de enlace de grupo o el protocolo de enlace de transición rápida (FT) es vulnerable a los ataques de reinstalación de claves. Estas secuencias de comandos se lanzarán una vez que hayamos tenido tiempo de limpiar sus instrucciones de uso.
También realizamos un script de prueba de concepto que explota la instalación de la llave (re) all-zero presente en ciertos dispositivos Android y Linux. Este script es el que usamos en el video de demostración . Será lanzado una vez que todos tengan una posibilidad razonable de actualizar sus dispositivos (y tuvimos un cambio para preparar el repositorio de códigos para su lanzamiento). Observamos que la fiabilidad de nuestro script de prueba de concepto puede depender de cuán cerca esté la víctima de la red real. Si la víctima está muy cerca de la red real, la secuencia de comandos puede fallar porque la víctima siempre se comunicará directamente con la red real, incluso si la víctima está (forzada) en un canal de Wi-Fi diferente a esta red.
Preguntas y Respuestas
¿Necesitamos ahora WPA3?
No, afortunadamente las implementaciones pueden parchearse en una forma compatible con versiones anteriores . Esto significa que un cliente parcheado puede comunicarse con un punto de acceso sin parcheo, y viceversa. En otras palabras, un cliente o puntos de acceso parcheado envía exactamente los mismos mensajes del protocolo de enlace que antes, y exactamente en los mismos momentos en el tiempo. Sin embargo, las actualizaciones de seguridad asegurarán que una clave solo se instala una vez, evitando nuestros ataques. De nuevo, actualice todos sus dispositivos una vez que las actualizaciones de seguridad estén disponibles.
¿Debo cambiar mi contraseña de Wi-Fi?
Cambiar la contraseña de su red Wi-Fi no impide (o atenúa) el ataque. Por lo tanto, no tiene que actualizar la contraseña de su red Wi-Fi. En su lugar, debe asegurarse de que todos sus dispositivos estén actualizados, y también debe actualizar el firmware de su enrutador. Después de actualizar su enrutador, puede opcionalmente cambiar la contraseña de Wi-Fi como precaución adicional.
Estoy usando WPA2 con solo AES. ¿Eso también es vulnerable?
Sí, esa configuración de red también es vulnerable. El ataque funciona contra WPA1 y WPA2, contra redes personales y empresariales, y contra cualquier conjunto de cifrado que se use (WPA-TKIP, AES-CCMP y GCMP). ¡Entonces todos deben actualizar sus dispositivos para evitar el ataque!
Usas la palabra "nosotros" en este sitio web. ¿Quienes somos nosotros?
Utilizo la palabra "nosotros" porque eso es lo que estoy acostumbrado a escribir en los documentos. En la práctica, todo el trabajo lo hago yo, siendo yo Mathy Vanhoef. Mi impresionante supervisor se agrega bajo una autoría honorífica al trabajo de investigación por su excelente orientación general. Pero todo el trabajo real se hizo por mi cuenta. Entonces, la lista de documentos académicos del autor no representa la división del trabajo :)
¿Es mi dispositivo vulnerable?
Probablemente. Cualquier dispositivo que use Wi-Fi es probablemente vulnerable. Póngase en contacto con su proveedor para obtener más información.
¿Qué sucede si no hay actualizaciones de seguridad para mi enrutador?
Nuestro ataque principal está en contra del protocolo de enlace de 4 vías, y no explota los puntos de acceso, sino que se dirige a los clientes. Por lo tanto, es posible que su enrutador no requiera actualizaciones de seguridad. Le recomendamos encarecidamente que contacte a su proveedor para obtener más detalles. Sin embargo, en general, puede intentar mitigar los ataques contra enrutadores y puntos de acceso deshabilitando la funcionalidad del cliente (que se utiliza, por ejemplo, en los modos de repetidor) y deshabilitando 802.11r (roaming rápido). Para los usuarios habituales del hogar, su prioridad debe ser la actualización de clientes, como computadoras portátiles y teléfonos inteligentes.
¿Cómo descubriste estas vulnerabilidades?
Cuando trabajé en la versión final de otro artículo, estaba revisando dos reclamos que hicimos sobre la implementación de OpenBSD del enlace de 4 vías. En cierto sentido, estaba desfalleciendo, porque se suponía que debía estar terminando el trabajo, en lugar de mirar el código. Pero allí estaba yo, inspeccionando un código que ya leí cien veces, para evitar tener que trabajar en el próximo párrafo. Fue en ese momento cuando me llamó la atención una llamada particular a ic_set_key . Esta función se invoca al procesar el mensaje 3 del protocolo de enlace de 4 vías, e instala la clave de par al controlador. Mientras miraba esa línea de código pensé: "Ha. Me pregunto qué pasa si esa función se llama dos veces". En el momento en que (correctamente) adiviné que llamarlo dos veces podría restablecer los nonces asociados a la clave. Y dado que el mensaje 3 puede ser retransmitido por el punto de acceso, en la práctica podría llamarse de hecho dos veces. "Es mejor hacer una nota de eso. Otros proveedores también pueden llamar a esa función dos veces. Pero terminemos primero este artículo ... " . Unas semanas más tarde, después de terminar el trabajo y completar otro trabajo, investigué esta nueva idea con más detalle. Y el resto es historia.
El protocolo de enlace de 4 vías fue matemáticamente probado como seguro. ¿Cómo es posible tu ataque?
La breve respuesta es que la prueba formal no asegura que una llave se instale una vez. En cambio, solo garantiza que la clave negociada permanezca en secreto, y que los mensajes de saludo no se pueden falsificar.
La respuesta más larga se menciona en la introducción de nuestro trabajo de investigación : nuestros ataques no violan las propiedades de seguridad probadas en el análisis formal del protocolo de enlace de 4 vías. En particular, estas pruebas indican que la clave de cifrado negociada sigue siendo privada, y que se confirma la identidad tanto del cliente como del punto de acceso (AP). Nuestros ataques no pierden la clave de cifrado. Además, aunque los marcos de datos normales se pueden falsificar si se usa TKIP o GCMP, un atacante no puede forjar mensajes de enlace y, por lo tanto, no puede suplantar al cliente o AP durante los protocolos de enlace. Por lo tanto, las propiedades que se probaron en el análisis formal del protocolo de enlace de 4 vías siguen siendo verdaderas. Sin embargo, el problema es que las pruebas no modelan la instalación de la clave. Dicho de otra manera, los modelos formales no definían cuándo debía instalarse una clave negociada. En la práctica, esto significa que la misma clave se puede instalar varias veces, restableciendo así los contadores de no repetición y repetición utilizados por el protocolo de cifrado (por ejemplo, mediante WPA-TKIP o AES-CCMP).
¿La gente está explotando esto en la naturaleza?
No estamos en condiciones de determinar si esta vulnerabilidad ha sido (o está siendo) explotada activamente en la naturaleza. Dicho esto, las reinstalaciones clave pueden ocurrir espontáneamente sin que haya un adversario presente. Esto puede suceder, por ejemplo, si se pierde el último mensaje de un protocolo de enlace, lo que provoca una retransmisión del mensaje anterior. Al procesar este mensaje retransmitido, las claves pueden volver a instalarse, lo que da como resultado la reutilización del nonce como en un ataque real.
¿Debo usar temporalmente WEP hasta que mis dispositivos estén parcheados?
¡NO! Siga usando WPA2.
¿Se actualizará el estándar Wi-Fi para abordar esto?
Parece que hay un acuerdo de que el estándar Wi-Fi debe actualizarse para evitar explícitamente nuestros ataques. Es probable que estas actualizaciones sean compatibles con versiones anteriores con implementaciones anteriores de WPA2. El tiempo dirá si y cómo se actualizará el estándar.
¿La Alianza Wi-Fi también aborda estas vulnerabilidades?
Para aquellos que no están familiarizados con Wi-Fi, Wi-Fi Alliance es una organización que certifica que los dispositivos Wi-Fi cumplen con ciertos estándares de interoperabilidad. Entre otras cosas, esto garantiza que los productos Wi-Fi de diferentes proveedores funcionen bien juntos.
Wi-Fi Alliance tiene un plan para ayudar a remediar las vulnerabilidades descubiertas en WPA2. Resumiendo, ellos:
1. Exigir pruebas para esta vulnerabilidad dentro de su red de laboratorio de certificación global.
2. Proporcione una herramienta de detección de vulnerabilidades para usar por cualquier miembro de Wi-Fi Alliance (esta herramienta se basa en mi propia herramienta de detección que determina si un dispositivo es vulnerable a algunos de los ataques de reinstalación de llaves descubiertos).
3. Comunique ampliamente los detalles sobre esta vulnerabilidad, incluidos los remedios, a los proveedores de dispositivos. Además, se recomienda a los vendedores que trabajen con sus proveedores de soluciones para integrar rápidamente los parches necesarios.
4. Comunique la importancia de que los usuarios se aseguren de que han instalado las últimas actualizaciones de seguridad recomendadas por los fabricantes de dispositivos.
¿Por qué utilizaste match.com como ejemplo en el video de demostración?
Los usuarios comparten mucha información personal en sitios web como match.com. Por lo tanto, este ejemplo resalta toda la información sensible que un atacante puede obtener, y es de esperar que con este ejemplo las personas también se den cuenta mejor del impacto potencial (personal). También esperamos que este ejemplo haga que las personas conozcan toda la información que estos sitios web de citas pueden recopilar.
¿Cómo se pueden prevenir estos tipos de errores?
Necesitamos más inspecciones rigurosas de implementaciones de protocolos. ¡Esto requiere ayuda e investigación adicional de la comunidad académica! Junto con otros investigadores, esperamos organizar talleres para mejorar y verificar la corrección de las implementaciones del protocolo de seguridad.
¿Por qué el nombre de dominio krackattacks.com?
En primer lugar, soy consciente de que los ataques KRACK son pleonasmos, ya que KRACK significa una instalación rápida y, por lo tanto, ya contiene la palabra ataque. Pero el nombre de dominio rima, por eso se usa.
¿Recibió recompensas de errores por esto?
Aún no he solicitado ninguna recompensa por errores, ni he recibido ninguna.
¿Cómo se compara este ataque con otros ataques contra WPA2?
Este es el primer ataque contra el protocolo WPA2 que no se basa en adivinar la contraseña. De hecho, otros ataques contra la red habilitada para WPA2 están en contra de las tecnologías circundantes, tales como Wi-Fi Protected Setup (WPS), o son ataques contra estándares más antiguos como WPA-TKIP. Dicho de otra manera, ninguno de los ataques existentes estaba en contra del protocolo de enlace de 4 vías o en contra de los paquetes de cifrado definidos en el protocolo WPA2. En contraste, nuestro ataque de reinstalación clave contra el protocolo de enlace de 4 vías (y contra otros protocolos de enlace) resalta las vulnerabilidades en el protocolo WPA2.
¿Otros protocolos también se ven afectados por los ataques de reinstalación de claves?
Esperamos que ciertas implementaciones de otros protocolos sean vulnerables a ataques similares. Por lo tanto, es una buena idea auditar las implementaciones del protocolo de seguridad con este ataque en mente. Sin embargo, consideramos que es improbable que otros estándares de protocolo se vean afectados por ataques similares (o al menos así lo esperamos). Sin embargo, ¡todavía es una buena idea auditar otros protocolos!
¿Hay una versión de mayor resolución del logotipo?
Si hay ¡Y muchas gracias a la persona que hizo el logo!
¿Cuándo notificó por primera vez a los proveedores sobre la vulnerabilidad?
Enviamos notificaciones a proveedores cuyos productos probamos a nosotros mismos alrededor del 14 de julio de 2017. Después de comunicarnos con estos proveedores, nos dimos cuenta de cuán generalizadas son las debilidades que descubrimos (solo entonces realmente me convencí a mí mismo de que era de hecho una debilidad del protocolo y no un conjunto de Errores de implementación). En ese momento, decidimos dejar que CERT/CC ayudara con la divulgación de las vulnerabilidades. A su vez, el CERT/CC envió una amplia notificación a los vendedores el 28 de agosto de 2017.
¿Por qué OpenBSD lanzó silenciosamente un parche antes del embargo?
OpenBSD fue notificado de la vulnerabilidad el 15 de julio de 2017, antes de que CERT/CC estuviera involucrado en la coordinación. Muy rápidamente, Theo de Raadt respondió y criticó la fecha límite de divulgación tentativa: "En el mundo de código abierto, si una persona escribe un diff y tiene que sentarse durante un mes, eso es muy desalentador" . Tenga en cuenta que escribí e incluyé un diff sugerido para OpenBSD ya, y que en ese momento la fecha límite de divulgación tentativa era hacia fines de agosto. Cómo compromiso, les permití parchear en silencio la vulnerabilidad. En retrospectiva, esta fue una mala decisión, ya que otros podrían redescubrir la vulnerabilidad mediante la inspección de su parche silencioso. Para evitar este problema en el futuro, OpenBSD ahora recibirá notificaciones de vulnerabilidad más cerca del final de un embargo.
¿Entonces esperas encontrar otras vulnerabilidades de Wi-Fi?
"Creo que recién estamos comenzando". - Master Chief, Halo 1
Recomendaciones de Security Hack Labs.
1. Si es posible, deshabilite su conexión mediante Wi-Fi hasta que se encuentre una solución al problema.
2. Use datos móviles en su celular en lugar de Wi-Fi.
4. Mantenga actualizado diariamente el software de su computadora, móvil y router.
Esperamos que esta publicación haya sido de utilidad, cualquier
inquietud o sugerencia dejarla en los comentarios en bien, en los medios
que indicamos a continuación.
Síguenos en Facebook, Twitter, unete a nuestra charla en Riot (Para charlar con nosotros online) o únete a Telegram.
Fuentes: https://www.krackattacks.com/
Fuentes: https://www.krackattacks.com/
