Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace pocos días. se dio a conocer la noticia de que un equipo de investigadores de la Universidad de California en San Diego ha demostrado la capacidad de recrear las claves privadas de host RSA de un servidor SSH mediante el análisis pasivo del tráfico SSH.

Las investigaciones publicadas muestran que cuando se utilizan firmas digitales basadas en el algoritmo RSA en SSH, los ataques que utilizan el método Lattice (Fault Attack) para recrear la clave privada RSA son adecuados para firmas digitales en caso de una falla de software o hardware durante el proceso de cálculo de la firma. La esencia del método es que al comparar las firmas digitales RSA correctas e incorrectas, se puede determinar el máximo común divisor, generando así uno de los números primos utilizados para generar la clave.

El cifrado RSA se basa en la operación de exponenciación de un gran número, mientras que la clave pública contiene el módulo y el grado. El módulo se forma a partir de dos números primos aleatorios, que sólo conoce el propietario de la clave privada. El ataque se puede aplicar a implementaciones RSA utilizando el teorema del resto chino y esquemas de relleno deterministas como PKCS#1 v1.5.

Se puede realizar un ataque a servidores en los que, por una conjunción de circunstancias o acciones del atacante, se produzcan fallos durante el cálculo de la firma digital al establecer una conexión SSH. Las fallas pueden ser de software (ejecución incorrecta de operaciones matemáticas, corrupción de memoria) o de hardware (errores en el funcionamiento de NVRAM y DRAM o fallas durante cortes de energía).

Una de las opciones para estimular fallos podrían ser los ataques de la clase RowHammer, que entre otras cosas, permite de forma remota o al procesar código JavaScript en un navegador lograr la distorsión del contenido de bits de memoria individuales durante la lectura cíclica intensiva de datos de los vecinos. células de memoria. Otra opción para provocar fallos podría ser la explotación de vulnerabilidades que provoquen desbordamientos del búfer y corrupción de datos con claves en la memoria.

Para llevar a cabo un ataque, basta con monitorear pasivamente las conexiones legítimas al servidor SSH hasta que se identifique una firma digital defectuosa en el tráfico, que puede usarse como fuente de información para reconstruir la clave privada RSA. Después de recrear la clave RSA del host, un atacante puede usar un ataque MITM para redirigir silenciosamente las solicitudes a un host falso que se hace pasar por un servidor SSH comprometido e interceptar los datos transmitidos a este servidor.

Al examinar una colección de datos de red interceptados que incluían aproximadamente 5200 millones de registros asociados con el uso del protocolo SSH, los investigadores identificaron aproximadamente 3200 millones de claves de host públicas y firmas digitales utilizadas durante la negociación de sesiones SSH. De ellos, 1.200 millones (39,1%) se generaron mediante el algoritmo RSA.

El grupo de investigadores menciona que:

En 593671 casos (0,048%) la firma RSA estaba dañada y no se pudo verificar, mientras que para 4962 firmas fallidas, pudimos utilizar el método de factorización Lattice para determinar la clave privada a partir de la clave pública conocida, lo que dio como resultado la reconstrucción de 189 pares de claves RSA únicos (en muchos casos, se usaron las mismas claves y dispositivos fallidos para generar diferentes firmas dañadas). Se necesitaron aproximadamente 26 horas de CPU para recrear las claves.

El problema sólo afecta a implementaciones específicas del protocolo SSH, utilizado principalmente en dispositivos integrados. Ademas de ello se menciona que OpenSSH no se ve afectado por este problema porque utiliza la biblioteca OpenSSL (o LibreSSL) para generar claves, que ha estado protegida contra ataques de fallas desde 2001.

Además, en OpenSSH, el esquema de firma digital ssh-rsa (basado en sha1) ha quedado obsoleto desde 2020 y deshabilitado en la versión 8.8 (la compatibilidad con los esquemas rsa-sha2-256 y rsa-sha2-512 permanece). El ataque podría ser potencialmente aplicable al protocolo IPsec, pero los investigadores no tenían suficientes datos experimentales para confirmar dicho ataque en la práctica.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.