SSHole: ya explotan la falla de OpenSSH que deja entrar sin contraseña en Alpine Linux

0 0 votos

Valora la Publicación

La vulnerabilidad de OpenSSH que deja entrar sin contraseña a servidores Linux con musl y sin PAM, como Alpine Linux, ya se está explotando. La firma Previdian registró los primeros intentos el 6 de noviembre, menos de nueve horas después de que se publicara la CVE.

La falla es CVE-2026-123158, con CVSS 8.1 y apodada SSHole. OpenSSH la corrigió el 5 de noviembre en la versión 10.6p2 y Alpine publicó ese mismo día paquetes corregidos para todas sus versiones desde la 3.16. Al 6 de noviembre no figura en el catálogo KEV de CISA.

Qué es lo que falla

OpenSSH es el servidor que usa casi todo Linux para la administración remota: el sshd que atiende cuando alguien se conecta por SSH. Para validar una contraseña puede delegar en PAM, el sistema de autenticación del sistema operativo, o hacerlo por su cuenta con la función crypt() de la biblioteca de C.

Alpine Linux no usa glibc sino musl, otra biblioteca de C más liviana, y su paquete openssh-server viene compilado sin PAM. En esa combinación aparecen tres detalles que, juntos, permiten entrar sin contraseña:

Las cuentas sin contraseña guardan un asterisco: en /etc/shadow, una cuenta que solo entra con clave SSH o que no tiene contraseña lleva * en lugar del hash.
La función de musl falla con contraseñas largas: con una contraseña de más de 256 bytes, crypt() de musl no calcula nada y devuelve justamente * como señal de error.
sshd compara los dos valores: el resultado del error (*) coincide con lo guardado para la cuenta (*) y el servidor da el login por bueno.

Según el análisis publicado con la CVE, el comportamiento viene de un cambio de 2016 que buscaba evitar la enumeración de usuarios (CVE-2016-6210). Para explotarla alcanza con conocer el nombre de una cuenta con * y enviar una contraseña de entre 257 y 1.024 bytes, sin ninguna credencial válida.

Qué sistemas están afectados

Según el aviso oficial de Alpine, un equipo es vulnerable si se cumplen las cuatro condiciones:

Corre openssh-server (sin PAM) o openssh-server-pam con UsePAM no.
Tiene PasswordAuthentication habilitado, que es el valor por defecto de OpenSSH.
Al menos una cuenta tiene * como contraseña.
Al menos una cuenta local tiene un hash del tipo $5$ o $6$ .

Afecta a Alpine 3.21 a 3.24 y edge, y también a las versiones 3.16 a 3.20, que tienen paquetes corregidos aunque ya no reciben actualizaciones regulares. No están afectados Dropbear, las distribuciones con glibc (Ubuntu, Debian, RHEL), los sistemas que no son Linux ni los que validan la contraseña con PAM.

Las cuentas en riesgo son root, que en Alpine viene como root:* desde la 3.16 aunque solo es alcanzable con PermitRootLogin yes; los usuarios creados solo con clave SSH; y el usuario alpine de las imágenes tiny-cloud de 3.18.11 a 3.24.3, que tiene * y doas sin contraseña, es decir, puede volverse root.

Los contenedores Docker que no ejecutan sshd adentro no están afectados. Sí hay que revisar las imágenes que lo incluyen: bastiones, jump hosts, runners de CI o appliances armados sobre Alpine.

La explotación ya empezó

La CVE se publicó el 5 de noviembre a las 15:46 UTC y el mismo día circuló una prueba de concepto pública. Los sensores de Previdian registraron los primeros intentos de explotación a las 00:05 UTC del 6 de noviembre, y la empresa la sumó a su propio catálogo de vulnerabilidades explotadas con confianza «confirmada».

El acceso que se obtiene es el de la cuenta comprometida, con sus permisos. Por eso pesa tanto el usuario alpine de las imágenes de nube: desde esa cuenta se llega a root sin otra contraseña.

Qué hacer

Actualizar y reiniciar el servicio: apk upgrade -U -a y después rc-service sshd restart. Actualizar el paquete no reinicia el sshd que está corriendo, así que sin el reinicio el equipo sigue expuesto.
Verificar la versión: las corregidas son, por ejemplo, 10.3_p1-r2 en 3.24, 10.2_p1-r1 en 3.23, 10.0_p1-r11 en 3.22 y 9.9_p2-r1 en 3.21 (la tabla completa está en el aviso de Alpine).
Si no se puede actualizar todavía: deshabilitar el login con contraseña creando /etc/ssh/sshd_config.d/00-no-passwords.conf con PasswordAuthentication no, validar con sshd -t, reiniciar y confirmar con sshd -T | grep -i passwordauthentication. Antes, comprobar que el acceso por clave funciona y no cerrar la sesión abierta.
Reconstruir las imágenes: las imágenes de contenedor y de nube que incluyen sshd se regeneran desde las versiones 3.21.10, 3.22.8, 3.23.8 o 3.24.4 en adelante.

Cómo revisar si alguien entró

Alpine recomienda buscar en /var/log/messages las líneas Accepted password for de cuentas que no tienen contraseña (alpine, root o usuarios que solo usan clave). También revisar el uso de doas, los usuarios y archivos creados en los últimos días y los authorized_keys de los equipos expuestos.

El criterio del aviso es directo: si no se puede descartar un login, el equipo se trata como comprometido.

¿Saben cuántos Alpine con SSH tienen en producción?

Alpine es la base de muchas imágenes livianas y de appliances que nadie recuerda haber instalado. El equipo de OpenSSH, además, anunció que va a sacar versiones con más frecuencia porque recibe cada vez más reportes hechos con ayuda de modelos de IA. ¿Tienen inventariados los equipos donde corre sshd sobre Alpine? Los leemos en los comentarios.

Fuentes

Escrito por

Pablo Ariel Di Loreto

Profesor. Informático. Fanático del helado de dulce de leche. Director de Ingeniería en MODO, y Secretario del Microsoft Users Group Asociación Civil. Además, soy owner de iniciativas como ConoSurTech y Aprender IT.

Ver todas las entradas de Pablo Ariel Di Loreto →