Algoritmo peligroso SHA-1 eliminado de las bibliotecas SSH


La complejidad de los ataques contra SHA-1. El precio se basa en el cálculo del precio de alquiler de un GTX 1060 a $ 35 / mes.

Mucho más tarde que todos los demás, pero los desarrolladores de las bibliotecas para SSH decidieron finalmente deshabilitar la función de cifrado SHA-1 obsoleta por defecto. Hoy, la selección de la clave de autenticación del servidor SHA-1, es decir, un conflicto con el prefijo seleccionado, en un clúster de GPU alquilado costará $ 45 mil , como se indica en la tabla anterior. Esto hace que el ataque sea accesible no solo para los servicios de inteligencia del estado, sino también para clientes comerciales.

La desactivación de SHA-1 por defecto fue anunciada simultáneamente por los desarrolladores de las bibliotecas OpenSSH openSSH ( notas de la versión ) y libssh ( cambio de código ).

El algoritmo Secure Hash (SHA) fue desarrollado por la NSA en colaboración con NIST. La primera versión de SHA-0 se introdujo en 1993, pero la NSA pronto retiró esta versión, citando un error que descubrieron que nunca se reveló.

Una versión fija de la NSA se publicó en 1995, se llamaba SHA-1.

La función hash criptográfica SHA-1 (Algoritmo de hash seguro 1) genera una cadena de 160 bits llamada resumen hash. Teóricamente, los resúmenes deben ser únicos para cada archivo, mensaje u otra entrada a la función. Como valor de entrada, SHA-1 acepta un mensaje no más de2641bit, es decir, aproximadamente 2 exabytes.

Está claro que el rango de valores de resumen es menor que el rango de valores de entrada. Pero en la práctica, las colisiones de resumen no deberían ser factibles, dadas las capacidades de rendimiento de los recursos informáticos existentes. Desafortunadamente, SHA-1 ya no cumple con este criterio.

En 2017, los empleados de Google y el Centro de Matemáticas y Ciencias de la Computación de Amsterdam introdujeron la primera forma de generar colisiones para SHA-1 .

Publicaron una prueba: dos documentos PDF con diferentes contenidos pero las mismas firmas digitales SHA-1.


  $ls -l sha*.pdf 
  -rw-r--r--@ 1 amichal  staff  422435 Feb 23 10:01 shattered-1.pdf
  -rw-r--r--@ 1 amichal  staff  422435 Feb 23 10:14 shattered-2.pdf
  $shasum -a 1 sha*.pdf
  38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-1.pdf
  38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-2.pdf



En el sitio web shattered.it , puede verificar cualquier archivo para ver si está incluido en el espacio de posibles colisiones. Es decir, ¿es posible recoger otro conjunto de datos (archivo) con el mismo hash. El vector de ataque es claro: un atacante puede reemplazar un archivo "bueno" con su copia con un marcador, una macro maliciosa o un descargador de troyanos. Y este archivo "malo" tendrá el mismo hash o firma digital.

En los últimos años, muchos programas y servicios han dejado de usar SHA-1 después de que los investigadores hayan demostrado formas prácticas de falsificar firmas digitales usando SHA-1. La opinión unánime de los expertos es que este algoritmo ahora no es seguro en casi todos los contextos de seguridad.

Google ha expresado durante mucho tiempo su desconfianza hacia SHA-1, especialmente porque usa esta función para firmar certificados TLS. En 2014, el equipo de desarrollo de Chrome anunció la eliminación gradual de SHA-1.

En 2017, los investigadores utilizaron la infraestructura de Google para realizar cálculos y verificar cálculos teóricos de cuánto tomaría la búsqueda de colisión. Los desarrolladores dicen que esta fue una de las computadoras más grandes jamás realizada por Google. En total, se realizaron nueve quintillones de cálculos SHA-1 (9.223.372.036.854.775.808), que requirieron 6.500 años de procesador en la primera fase y 110 años de GPU en la segunda fase del ataque.

Bloques de mensajes con el mismo hash SHA-1


En 2019, los investigadores Gaetan Laurent y Thomas Peyrin demostraron un ataque al encontrar un conflicto con un prefijo elegido, lo que tiene sentido práctico para seleccionar claves de cifrado PGP / GnuPG específicas. Finalmente, en enero de 2020, los autores lograron optimizar el ataque en un orden de magnitud y reducir su costo teórico a un precio comercialmente aceptable (ver tabla anterior y pdf ). Para demostrarlo, crearon un par de claves PGP / GnuPG diferentes con los mismos certificados SHA-1.

Como defensa contra un ataque para encontrar colisiones SHA-1, se recomienda cambiar a mejores funciones hash criptográficas SHA-256 y SHA-3.

Los desarrolladores de OpenSSH, que escribieron en las notas de la última versión, citan este estudio de enero de 2020: “Ahora puedes realizar ataques con el prefijo seleccionado usando el algoritmo SHA-1 por menos de 50 mil dólares estadounidenses. Por este motivo, en un futuro próximo desactivaremos el algoritmo de firma de clave pública ssh-rsa predeterminado. Desafortunadamente, este algoritmo todavía se usa ampliamente. A pesar de la existencia de mejores alternativas, ha sido durante mucho tiempo el único algoritmo de firma de clave pública definido por el SSH RFC original ”.

Entre las mejores alternativas, los desarrolladores de OpenSSH llamaron a los algoritmos RFC8332 RSA SHA-2 (compatibles con OpenSSH 7.2 y ya utilizados de forma predeterminada si el servidor y el cliente lo admiten), ssh-ed25519 (compatible con 6.5) y RFC5656 ECDSA (desde la versión 5.7) .

Para verificar que el servidor utiliza el algoritmo SHA-1 débil al generar la clave pública para la autenticación, intente conectarse a él después de eliminar el algoritmo ssh-rsa de la lista de permitidos en ssh (1) :

ssh -oHostKeyAlgorithms=-ssh-rsa user@host

Si la verificación falla y otros tipos de claves no están disponibles, entonces el software del servidor debe actualizarse.

En futuras versiones de OpenSSH, la opción UpdateHostKeys estará habilitada de forma predeterminada, en la cual el cliente cambiará automáticamente a los mejores algoritmos. Se puede activar manualmente.

Aparentemente, el apagado completo de SHA-1 tomará mucho tiempo. Gaetan Laurent, del Instituto Nacional de Investigación en Ciencias de la Computación y Automatización (Francia), uno de los coautores del estudio de enero, no espera que los desarrolladores de OpenSSH hagan esto rápidamente: "Cuando deshabiliten completamente SHA-1, será imposible conectarse desde la nueva versión de OpenSSH al dispositivo con el viejo Servidor SSH, escribeél. - Probablemente, antes de esto, tomarán una serie de pasos graduales (con fuertes advertencias). Por otro lado, en los sistemas embebidos con SSH que no se han actualizado durante muchos años, probablemente haya muchos problemas de seguridad, por lo que podría no ser tan malo interrumpir su trabajo ... De todos modos, estoy bastante satisfecho con este movimiento, esto exactamente lo que queríamos lograr :-) ".

Después de que OpenSSH y libssh anunciaron planes para deshabilitar SHA-1, la lista de usuarios de SHA-1 se acortó, pero no desapareció. La función aún es compatible con las últimas versiones de la biblioteca OpenSSL, que muchos sitios web y servicios de Internet utilizan para implementar HTTPS y otros protocolos de cifrado. La última versión del compilador GNU Collection, lanzada a principios de este mes, está firmada digitalmente con el hash SHA-1.

Linus Torvaldsdijoque en los repositorios de Git las colisiones hash no representan un riesgo de seguridad. Explicó que hay una gran diferencia entre usar un hash criptográfico para firmas digitales en sistemas de encriptación y generar "identificación de contenido" en un sistema como Git. Cuando todos los datos están en el dominio público, un ataque real es casi imposible. Los autores del trabajo científico dan un ejemplo de ataque a documentos con el mismo prefijo. Este ataque es exitoso porque el prefijo en sí está "cerrado" dentro del documento, como un blob. Si tenemos código abierto en el repositorio, entonces este es un asunto completamente diferente. Difícilmente es posible hacer dicho prefijo desde el código fuente (solo desde blob). En otras palabras, para crear un prefijo idéntico y luego generar ramas de código con los mismos hash SHA-1, deberá inyectar algunos datos aleatorios en el código, que se notará de inmediato. Dice Linusque hay lugares donde puedes ocultar los datos, perogit fsckYa atrapa tales trucos. Sin embargo, Linus tiene un plan para evitar el uso de SHA-1 para que nadie tenga que convertir sus repositorios.

All Articles