La vulnerabilidad sshole en sistemas Linux con musl libc, que permitía acceso root mediante contraseñas largas. OpenSSH ya lanzó la versión 10.6p2 para corregir este fallo de seguridad.





En ciertos sistemas Linux, un atacante podría obtener acceso root introduciendo una contraseña de más de 256 bytes. La vulnerabilidad, apodada *sshole (sshhole.com) por el investigador de Wakefield Özgün Kültekin, quien la descubrió, solo puede explotarse en condiciones muy específicas.

El fallo afecta a ciertos sistemas Linux que utilizan musl libc en lugar de la biblioteca GNU C tradicional, e incluso entonces, solo a aquellos que ejecutan el demonio de shell seguro de OpenSSH sin Módulos de Autenticación Enchufables (PAM) y con la autenticación por contraseña habilitada.

Si se cumplen esas condiciones, y al menos otra cuenta tiene un hash de contraseña válido, se podría acceder a cuentas que no deberían aceptar contraseñas, como root, usuarios de despliegue solo con clave y usuarios de LDAP, suministrando una contraseña de entre 257 y 1,024 caracteres. Las cuentas objetivo deben tener un asterisco (*) en su campo de contraseña, y el inicio de sesión directo de root sigue sujeto a la configuración de OpenSSH.

Musl libc es común en sistemas Linux embebidos debido a su baja huella. Más crítico aún, es también la biblioteca C estándar para Alpine Linux, que proporciona imágenes oficiales de la nube tanto para AWS como para Azure. Algunos sistemas Alpine que se ejecutan en esos entornos podrían, por lo tanto, ser vulnerables, dependiendo de su configuración.

El amanecer del *sshole

La vulnerabilidad en OpenSSH en sistemas Linux basados en musl se remonta a 2016, pero Kültekin explica que sus raíces son mucho más profundas, llegando en realidad a la era de BSD Unix.

En 1980, el cofundador de Sun Microsystems y peso pesado de BSD Unix, Bill Joy, estuvo involucrado en el desarrollo de BSD Unix, cuyo archivo de contraseñas contenía un único asterisco en la entrada /etc/passwd para el usuario daemon. El asterisco no era un hash de contraseña y, efectivamente, desactivaba la autenticación por contraseña para esa cuenta.

Hoy en día, los hashes de contraseña suelen residir en /etc/shadow y contienen información cifrada que el sistema utiliza para verificar una contraseña en texto plano introducida por un usuario. Los asteriscos siguen presentes en las cuentas que no deben aceptar inicios de sesión con contraseña, pero como explica Kültekin en su informe, eso no es exactamente una forma infalible de mantener a la gente fuera.

La función crypt(), que genera hashes de contraseñas para compararlos con los valores almacenados, puede devolver NULL si no puede computar un hash. Las aplicaciones que no comprueban ese resultado pueden bloquearse. Los desarrolladores de musl libc optaron en su lugar por devolver un único carácter para ciertos fallos, y eligieron el asterisco.

Musl también añadió el hashing de contraseñas basado en SHA-512 aproximadamente al mismo tiempo, lo cual, según señala Kültekin, se vuelve más lento cuanto más larga es la contraseña, lo que podría provocar una denegación de servicio si alguien inunda un servidor con una contraseña súper larga. Musl limitó las contraseñas a 256 bytes, y probablemente ya veis hacia dónde va esto.

En 2016, OpenSSH introdujo una solución temporal para evitar que los atacantes enumeraran nombres de cuentas válidas a través de SSH. Antes del cambio, sshd podía rechazar los intentos de autenticación de usuarios inexistentes más rápidamente que los de cuentas válidas. Los intentos contra cuentas válidas tardaban más porque el servidor tenía que procesar el hash de la contraseña suministrada antes de rechazarla. La solución fue hacer que sshd realizara un hashing de contraseña ficticio para usuarios inválidos, utilizando un algoritmo de hashing y una sal adecuados para reducir las diferencias en los tiempos de respuesta.


En los sistemas Linux basados en musl afectados, las cuentas marcadas con un asterisco en lugar de un hash de contraseña podrían ser abiertas suministrando una contraseña de más de 256 bytes, un fallo que data de 2016. Cualquier sistema Linux basado en musl que ejecute una configuración de OpenSSH vulnerable sin PAM, con la autenticación por contraseña habilitada, al menos una cuenta marcada con un asterisco y otra cuenta con un hash de contraseña válido podría ser vulnerable a un ataque *sshole.

Afortunadamente, OpenSSH actuó rápido para solucionar este problema (openssh.org), y cualquier versión de OpenSSH 10.6p2 (lanzada el jueves) o posterior está protegida. Alternativamente, si no puedes actualizar tu implementación de OpenSSH en un sistema afectado, simplemente desactiva la autenticación por contraseña y reinicia el demonio SSH y deberías estar listo.

No hay indicios de que los sistemas vulnerables hayan sido explotados, pero si quieres comprobarlo, Kültekin ha incluido (sshhole.com) un comando CLI sencillo en su informe que puede utilizarse para verificar si alguna cuenta sin contraseña en una máquina sensible ha aceptado una contraseña recientemente. 

Fuente:
TheRegister