SWEET32: ataque a los protocolos de 3DES y Blowfish de 64 bits
Parece que no sólo RC4 debe morir definitivamente. Los investigadores han publicado investigaciones que indican que RC4 pronto podría tener la compañía de Triple-DES (3DES) y Blowfish de 64 bits. Los nuevos ataques permiten la recuperación de cookies de autenticación en el tráfico protegido 3DES en HTTPS y la recuperación de nombres de usuario y contraseñas en tráfico de OpenVPN a través de Blowfish.
Investigadores Gaetan Leurent y Karthikeyan Bhargavan de Inria, Francia, presentarán formalmente su paper "On the Practical (In-)Security of 64-Bit Ciphers" en octubre en la Conferencia de ACM "Computer and Communications Security" en Austria.
El ataque, llamado SWEET32 [PDF], es un ataque de colisión contra estos algoritmos de cifrado en modo CBC.
Los investigadores dijeron que 3DES todavía es soportado por servidores HTTPS en el 1 o 2 por ciento del tráfico. "Los navegadores no han matado 3DES porque están esperando hasta que tenga menos uso. En este momento, el 2% es mucho tráfico".
En paquetes de datos pequeños (como una cookie), la mayor parte del tiempo, el bloque de texto cifrado resultante es único. Sin embargo, cuando se cifran muchos de bloques de mensajes con la misma clave, en algún momento, se espera tener una colisión con las entradas del cifrado y se puede ver una colisión en las salidas del cifrado (un clásico ataque de cumpleaños). Es decir, se verá un bloque de texto cifrado igual a otro bloque cifrado anterior (P ⊕ IV = P' ⊕ IV').
Estas suites de cifrado de 64-bit son vulnerables a Chosen Plain Text Attacks, aún si el atacante no puede recuperar la clave de cifrado."Al detectar esta colisión en la salida, sabemos que tenía que haber una colisión en la entrada, debido al modo de trabajo de CBC. Es un ataque muy conocido en el modo de CBC: si se cifran demasiados bloques, en algún momento se tiene una colisión y se obtiene el XOR de los dos mensajes. Basándose en esto, un atacante puede obtener la cookie de autenticación de la víctima".
Estos ataques son muy bien conocidos en la teoría pero en este caso los investigadores han demostrado cómo llevarlos a la práctica. Cada solicitud incluye la cookie de autenticación del sitio y, si el atacante es capaz de enviar al menos 2^32 (4 mil millones) consultas y capturar todas esas solicitudes, tendrá una colisión y finalmente podrá recuperar la cookie de sesión. Según los investigadores, la primera colisión se espera después de unos 32 GB de datos, que si bien es mucho, no es imposible.
En HTTPS con cifrado 3DES se podría recuperar la cookie de sesión de HTTPS capturando alrededor de 785GB de tráfico. Los investigadores han automatizado y acelerado el proceso, haciendo que en menos de 2 días se pueda obtener la cookie para el robo de identidad. En conexiones HTTPS no es especialmente grave ya que no se intercambia tanto tráfico, pero en conexiones OpenVPN con Blowfish sí es grave.
A través de la herramienta cipherscan se puede realizar un análisis de las Top 1M de Alexa, 86% utiliza TLS con 3DES.
La mitigación más simple es dejar de utilizar los cifrados de bloques pequeños, retirar los métodos de cifrado basados en CBC y pasar a AES de 128 bits. También se puede configurar la aplicación para manejar sesiones más cortas.
OpenVPN 2.3.x recomienda utilizar AES-256-CBC o AES-128-CBC. OpenVPN 2.4 y posteriores agregaran soporte para GCM y se recomendará utilizar AES-256-GCM o AES-128-GCM.
Por su parte, OpenSSL retirará 3DES de la versión la 1.1.0 (CVE-2016-2183) y cambiará la categoría de cifrado de alta seguridad a medio en las versiones 1.0.2 y 1.0.1.
Fuente: ThreatPost | Cryptography Engineering
Investigadores Gaetan Leurent y Karthikeyan Bhargavan de Inria, Francia, presentarán formalmente su paper "On the Practical (In-)Security of 64-Bit Ciphers" en octubre en la Conferencia de ACM "Computer and Communications Security" en Austria.
El ataque, llamado SWEET32 [PDF], es un ataque de colisión contra estos algoritmos de cifrado en modo CBC.
En paquetes de datos pequeños (como una cookie), la mayor parte del tiempo, el bloque de texto cifrado resultante es único. Sin embargo, cuando se cifran muchos de bloques de mensajes con la misma clave, en algún momento, se espera tener una colisión con las entradas del cifrado y se puede ver una colisión en las salidas del cifrado (un clásico ataque de cumpleaños). Es decir, se verá un bloque de texto cifrado igual a otro bloque cifrado anterior (P ⊕ IV = P' ⊕ IV').
Estas suites de cifrado de 64-bit son vulnerables a Chosen Plain Text Attacks, aún si el atacante no puede recuperar la clave de cifrado."Al detectar esta colisión en la salida, sabemos que tenía que haber una colisión en la entrada, debido al modo de trabajo de CBC. Es un ataque muy conocido en el modo de CBC: si se cifran demasiados bloques, en algún momento se tiene una colisión y se obtiene el XOR de los dos mensajes. Basándose en esto, un atacante puede obtener la cookie de autenticación de la víctima".
Estos ataques son muy bien conocidos en la teoría pero en este caso los investigadores han demostrado cómo llevarlos a la práctica. Cada solicitud incluye la cookie de autenticación del sitio y, si el atacante es capaz de enviar al menos 2^32 (4 mil millones) consultas y capturar todas esas solicitudes, tendrá una colisión y finalmente podrá recuperar la cookie de sesión. Según los investigadores, la primera colisión se espera después de unos 32 GB de datos, que si bien es mucho, no es imposible.
En HTTPS con cifrado 3DES se podría recuperar la cookie de sesión de HTTPS capturando alrededor de 785GB de tráfico. Los investigadores han automatizado y acelerado el proceso, haciendo que en menos de 2 días se pueda obtener la cookie para el robo de identidad. En conexiones HTTPS no es especialmente grave ya que no se intercambia tanto tráfico, pero en conexiones OpenVPN con Blowfish sí es grave.
A través de la herramienta cipherscan se puede realizar un análisis de las Top 1M de Alexa, 86% utiliza TLS con 3DES.
OpenVPN 2.3.x recomienda utilizar AES-256-CBC o AES-128-CBC. OpenVPN 2.4 y posteriores agregaran soporte para GCM y se recomendará utilizar AES-256-GCM o AES-128-GCM.
Por su parte, OpenSSL retirará 3DES de la versión la 1.1.0 (CVE-2016-2183) y cambiará la categoría de cifrado de alta seguridad a medio en las versiones 1.0.2 y 1.0.1.
Fuente: ThreatPost | Cryptography Engineering
Muy bien. Gracias por compartirlo.
ResponderBorrar