información sobre el nuevo (CVE-2020-1968) en el protocolo TLS, conocido como
y que permite, en circunstancias muy raras, determinar la clave primaria preliminar (pre-master), que se puede usar para descifrar conexiones TLS, incluyendo HTTPS, al interceptar el tráfico en tránsito (MITM). Se observa que el ataque es muy complejo de implementar en la práctica y tiene un carácter más teórico. Para llevar a cabo este ataque se requiere una configuración específica del servidor TLS y la capacidad de medir con gran precisión el tiempo que tarda el servidor en procesar operaciones.
El problema está presente directamente en la especificación de TLS y afecta solo a las conexiones que utilizan cifrados basados en el protocolo de intercambio de claves DH (Diffie-Hellman, TLS_DH_*). Con los cifrados ECDH, el problema no se presenta y permanecen seguros. Solo los protocolos TLS hasta la versión 1.2 inclusive son vulnerables; el protocolo TLS 1.3 no es susceptible a este problema. La vulnerabilidad se presenta en las implementaciones de TLS que reutilizan la clave secreta DH en diferentes conexiones TLS (tal comportamiento se observa en aproximadamente el 4.4% de los servidores según el ranking de Alexa Top 1M).
En OpenSSL 1.0.2e y versiones anteriores, la clave primaria DH se reutiliza en todas las conexiones del servidor, a menos que se active explícitamente la opción SSL_OP_SINGLE_DH_USE. A partir de OpenSSL 1.0.2f, la clave primaria DH se reutiliza solo cuando se utilizan cifrados DH estáticos ('DH-*', por ejemplo, 'DH-RSA-AES256-SHA'). En OpenSSL 1.1.1, la vulnerabilidad no se presenta, ya que en esta rama no se utiliza la clave primaria DH y no se aplican cifrados DH estáticos.
Al utilizar el método de intercambio de claves DH, ambas partes de la conexión generan claves privadas aleatorias (denominadas clave 'a' y clave 'b'), a partir de las cuales se calculan y se envían las claves públicas (ga mod p y gb mod p). Después de recibir las claves públicas, cada parte calcula la clave primaria compartida (gab mod p), que se utiliza para formar las claves de sesión. El ataque Raccoon permite determinar la clave primaria analizando información a través de canales externos, basándose en que las especificaciones de TLS hasta la versión 1.2 exigen descartar todos los bytes iniciales nulos de la clave primaria antes de realizar cálculos que la involucren.
Incluyendo que la clave primaria recortada se transmite a la función de generación de la clave de sesión, basada en funciones hash con diferentes retardos en el procesamiento de diferentes datos. La medida precisa del tiempo que toma al servidor realizar operaciones con la clave permite al atacante determinar las pistas (oracle) que permiten deducir si la clave primaria comienza en cero o no. Por ejemplo, el atacante puede interceptar la clave pública enviada por el cliente (ga), reenviarla al servidor y determinar
si la clave primaria resultante comienza en cero.
La simple determinación de un byte de la clave no aporta nada, pero al interceptar el valor 'ga' transmitido durante el apretón de manos de la conexión por parte del cliente, el atacante puede formar un conjunto de otros valores relacionados con 'ga' y enviarlos al servidor en sesiones de apretón de manos separadas. Al generar y enviar los valores 'gri*ga', el atacante puede, mediante el análisis del cambio en los retardos en la respuesta del servidor, determinar los valores que llevan a obtener claves primarias que comienzan en cero. Al identificar tales valores, el atacante puede formular un conjunto de ecuaciones para y calcular la clave primaria original.
En OpenSSL, las vulnerabilidades tienen un bajo nivel de peligrosidad, y la solución se redujo a mover en la versión 1.0.2w los cifrados problemáticos 'TLS_DH_*' a una categoría de cifrados desactivada por defecto con un nivel de seguridad insuficiente ('weak-ssl-ciphers'). De manera similar, los desarrolladores de Mozilla en la biblioteca NSS, utilizada en Firefox, han desactivado los conjuntos de cifrados DH y DHE. A partir de Firefox 78, los cifrados problemáticos están desactivados. En Chrome, el soporte para DH se suspendió ya en 2016. Las bibliotecas BearSSL, BoringSSL, Botan, Mbed TLS y s2n no son vulnerables al problema, ya que no soportan cifrados DH o versiones estáticas de cifrados DH.
Se señalan también problemas adicionales () en el stack TLS de los dispositivos F5 BIG-IP, lo que hace que el ataque sea más realista. En particular, se han identificado desviaciones en el comportamiento de los dispositivos cuando hay un byte nulo al inicio de la clave primaria, que se puede utilizar en lugar de medir el tiempo preciso de retraso durante los cálculos.
Fuente: opennet.ru
