Se ha descubierto una vulnerabilidad llamada "*sshole" que afecta a servidores OpenSSH en distribuciones Linux basadas en musl (como Alpine Linux). El fallo permite que atacantes accedan a cuentas que tienen bloqueada la autenticación por contraseña simplemente ingresando una contraseña excesivamente larga. Para solucionarlo, se recomienda actualizar a OpenSSH 10.6p2 o desactivar la autenticación por contraseña en la configuración del servidor.



Un fallo recientemente revelado que involucra a OpenSSH y musl, apodado "*sshole", permite a los atacantes iniciar sesión en ciertas cuentas de Alpine Linux y otras cuentas de Linux basadas en musl configuradas para bloquear la autenticación por contraseña, simplemente introduciendo una contraseña de tamaño excesivo.

El fallo solo afecta a los servidores OpenSSH que se ejecutan en distribuciones de Linux que utilizan la biblioteca C musl, incluidas Alpine Linux, OpenWrt, Buildroot y Yocto, bajo ciertas configuraciones de autenticación.

El investigador de seguridad Ozgun Kultekin, quien descubrió y publicó hoy los detalles sobre la vulnerabilidad, afirma que el fallo existe desde 2016 y se deriva de la forma en que OpenSSH maneja los errores de verificación de contraseñas en sistemas que utilizan la biblioteca C musl.



Las cuentas de Linux pueden configurarse para evitar los inicios de sesión con contraseña sustituyendo el hash de su contraseña por un asterisco (*) en el archivo /etc/shadow. Debido a que este no es un hash de contraseña válido, ninguna contraseña debería permitir el acceso a esas cuentas.

Sin embargo, un parche introducido en OpenSSH en 2016 para solucionar una vulnerabilidad de enumeración de nombres de usuario [CVE-2016-6210] cambió la forma en que OpenSSH manejaba las cuentas sin hashes de contraseña utilizables.

Para evitar que los atacantes identificaran nombres de usuario válidos a través de diferentes tiempos de respuesta, OpenSSH fue modificado para realizar el hash de la contraseña incluso cuando una cuenta no tenía un hash utilizable, incluidas las cuentas configuradas con * para bloquear los inicios de sesión.

El problema es que la función crypt() de la biblioteca C musl también devuelve * cuando el hash de la contraseña falla, incluso cuando una contraseña enviada excede su límite de 256 bytes.

Esto significa que un atacante puede enviar una contraseña excesivamente grande y hacer que OpenSSH compare el * devuelto con el * almacenado en la cuenta, resultando en un inicio de sesión exitoso.

Para ser claros, el fallo no permite a los atacantes eludir las contraseñas en cuentas que tienen hashes de contraseña válidos.

Kultekin afirma que la explotación requiere las siguientes condiciones:

• * OpenSSH se ejecuta en un sistema Linux basado en musl, como Alpine Linux, OpenWrt, Buildroot o Yocto.
• * La autenticación PAM está desactivada, como ocurre por defecto en el paquete openssh-server de Alpine Linux.
• * La autenticación por contraseña de SSH está habilitada.
• * Al menos una cuenta tiene un asterisco (*) como hash de contraseña.
• * Otra cuenta tiene un hash de contraseña válido.

El investigador advierte que las imágenes oficiales de la nube de AWS y Azure de Alpine Linux tienen una cuenta 'alpine' predeterminada afectada con privilegios 'doas' sin contraseña, lo que podría permitir a los atacantes obtener acceso root.

Los sistemas que utilizan glibc, incluidos Debian, Ubuntu y Fedora, y aquellos que utilizan la autenticación PAM no son vulnerables a este ataque.

Kultekin dice que descubrió la vulnerabilidad utilizando agentes de IA que realizaron unos 17,600 tests de autenticación con diferentes configuraciones de OpenSSH, hashes de contraseña malformados y contraseñas de tamaño excesivo.

La vulnerabilidad ha sido corregida en OpenSSH 10.6p2, y se recomienda a los administradores de Alpine Linux que actualicen sus paquetes de OpenSSH mediante apk upgrade openssh.

Los administradores que no puedan instalar la actualización inmediatamente pueden mitigar el problema desactivando la autenticación por contraseña de SSH con PasswordAuthentication no en la configuración de su servidor SSH y reiniciando el servicio.

Kultekin señala que los administradores también pueden buscar signos de explotación examinando los registros de autenticación de SSH en busca de inicios de sesión basados en contraseña para cuentas que no deberían permitirlos.

En Alpine Linux, el siguiente comando puede revelar inicios de sesión exitosos por contraseña de SSH:

grep "Accepted password" /var/log/messages

Si los registros muestran un inicio de sesión exitoso para la cuenta alpine, los administradores pueden verificar si esa cuenta tiene desactivada la autenticación por contraseña:

grep '^alpine:' /etc/shadow

Si el campo de contraseña de la cuenta contiene *, pero los registros de SSH muestran un inicio de sesión exitoso, podría indicar que la vulnerabilidad fue explotada.


Fuente:
BleepingComputer