SSHole — una vulnerabilidad que permite conectarse por SSH sin contraseña en sistemas con Musl

Los desarrolladores de OpenSSH han publicado una actualización de emergencia, OpenSSH 10.6p2, que incluye protección contra una vulnerabilidad crítica (CVE no asignada), apodada "SSHole", que permite eludir la autenticación. En sistemas con la biblioteca Musl, la vulnerabilidad permite conectarse a un usuario para el cual no se ha establecido contraseña, ingresando cualquier contraseña que contenga más de 256 caracteres. El problema afecta a las distribuciones de Linux que utilizan la biblioteca estándar musl, pero no utilizan PAM (Módulos de Autenticación Pluggables), como OpenWRT, Alpine, Buildroot y Yocto. Representa un peligro especial ya que a menudo el acceso por contraseña está bloqueado para el usuario root, lo que brinda la oportunidad a cualquier persona de conectarse de forma remota con derechos de administrador.

La falla que conduce a la vulnerabilidad no está en el código de OpenSSH, sino que se explota a través de sshd. Debido a la gravedad del problema, en la versión OpenSSH 10.6p2 se ha propuesto una solución alternativa para bloquear la vulnerabilidad. Se recomienda a los propietarios de sistemas afectados que no esperen actualizaciones, sino que desactiven inmediatamente la autenticación por contraseña mediante el parámetro "PasswordAuthentication no" en /etc/ssh/sshd_config o deshabilitar completamente SSH.

El problema no se manifiesta en sistemas distintos a Linux, en entornos de Linux basados en glibc, ni en sistemas que utilizan PAM en la autenticación por contraseña. La corrección ya está disponible en Alpine y OpenWRT.

La vulnerabilidad está relacionada con una interacción incorrecta entre OpenSSH y la función crypt() de musl. Para protegerse contra la determinación de la existencia de usuarios mediante el análisis de las diferencias en el tiempo de procesamiento de solicitudes, desde 2016 OpenSSH utiliza un procedimiento estándar de verificación de contraseña al comprobar cuentas sin contraseña: llama a la función "crypt(contrasena proporcionada, sal)" con la sal de otro usuario que tiene un hash de contraseña válido, y luego compara el hash devuelto por la función crypt con el valor del campo que contiene el hash de contraseña.

Sin embargo, en musl, la función crypt() para hashes SHA-512 devuelve el carácter "*" si la longitud de la contraseña proporcionada excede los 256 bytes (límite introducido en 2012 para protegerse contra ataques DoS, ya que el envío de valores grandes genera una gran carga en la CPU). Este mismo carácter se utiliza en el campo del hash de contraseña en "/etc/shadow" para indicar cuentas para las cuales la autenticación por contraseña está bloqueada.

Como resultado, un atacante que pueda conectarse a un servidor SSH puede acceder a cualquier cuenta cuyo campo de contraseña en «/etc/shadow» contenga el símbolo «*», enviando una cadena de longitud de 257 a 1024 bytes. Este problema afecta a muchas imágenes de Docker existentes construidas con Alpine Linux, así como a las imágenes estándar de Alpine para sistemas en la nube de AWS y Azure, donde el usuario root tiene un símbolo «*» en lugar de un hash de contraseña.

Es notable que, originalmente, en las imágenes oficiales de Docker que utilizan Alpine, desde 2015 se establecía una contraseña vacía para el root, y tras identificarse este hecho, se colocó el símbolo «!». Sin embargo, su presencia bloqueaba el acceso mediante claves SSH, por lo que desde 2022 el símbolo para bloquear el acceso por contraseña fue reemplazado por «*».

Fuente: opennet.ru