OpenSSH ha publicado una corrección de emergencia (versión 10.6p2) para un fallo que permite a un atacante autenticarse en cuentas sin contraseña en sistemas afectados que ejecutan el servidor openssh-server. El problema se manifiesta en entornos que usan la biblioteca C musl —principalmente Alpine Linux y otras distribuciones embebidas— cuando sshd no utiliza PAM y la autenticación por contraseña está habilitada.
Qué ocurre y por qué afecta a musl
Cuando sshd comprueba contraseñas sin pasar por PAM, cifra el intento con la función crypt() y compara el resultado con el campo almacenado en /etc/shadow. En cuentas sin contraseña dicho campo contiene solo un asterisco (*). En sistemas construidos con musl, crypt() devuelve * para intentos de contraseñas que superan 256 bytes en los tipos de hash $5$ y $6$, lo que coincide con el valor que indica ausencia de contraseña y provoca que sshd acepte la autenticación.
El rango de contraseñas explotables va de 257 a 1.024 bytes, donde el límite superior es impuesto por sshd. La causa raíz combina un comportamiento de musl (que retorna * en fallos de crypt() en lugar de NULL) y el hecho de que sshd, al encontrar un campo de contraseña muy corto, reutiliza la sal de otra cuenta con contraseña para comparar hashes.
A quién afecta
- Sistemas que ejecutan openssh-server compilado sin PAM (por ejemplo, el paquete estándar de Alpine Linux).
- Servidores con PasswordAuthentication habilitado.
- Máquinas donde exista al menos una cuenta con contraseña en /etc/shadow; una sola cuenta con contraseña basta para exponer otras cuentas sin contraseña.
No están afectados los sistemas que usan glibc, aquellos que verifican contraseñas mediante PAM, contenedores que no ejecutan sshd, instancias de nube configuradas por cloud-init que establecen PasswordAuthentication no o cuentas bloqueadas con ! en /etc/shadow.
Impacto práctico
Un atacante necesita acceso de red al servidor, conocer un nombre de usuario de una cuenta sin contraseña (por ejemplo, cuentas configuradas para acceso solo por clave) y enviar una contraseña larga en el rango descrito. Según las notas, el ataque tiene éxito con un solo intento por conexión y puede permitir, por ejemplo, entrar como usuario alpine en imágenes tiny-cloud si posteriormente existe cualquier hash $6$ en el sistema y ese usuario puede elevar privilegios con doas.
Qué deben hacer administradores y propietarios
- Actualizar OpenSSH a la versión 10.6p2 o instalar los paquetes corregidos publicados por Alpine para las ramas soportadas; tras actualizar, reiniciar el servicio sshd (la actualización del paquete no reinicia el demonio automáticamente).
- Si no es posible actualizar de inmediato: desactivar la autenticación por contraseña estableciendo PasswordAuthentication no en la configuración de sshd. Antes de aplicar el cambio, verifique que el acceso por clave funciona y mantenga la sesión actual abierta hasta comprobar un nuevo inicio de sesión.
- Comprobar /var/log/messages en busca de líneas de sshd que indiquen Accepted password for una cuenta que debería ser sin contraseña y auditar cuentas, uso de doas, claves autorizadas y usuarios recientemente creados.
- Si no se puede descartar un acceso no autorizado, tratar la máquina como comprometida y proceder con medidas de remediación y análisis forense.
Alcance y recomendaciones adicionales
El fallo no se limita a Alpine: otros sistemas basados en musl (mencionados por el investigador que lo reportó) como Buildroot, Yocto u OpenWrt donde se haya instalado OpenSSH en lugar de Dropbear deberían revisarse. En OpenWrt el servidor predeterminado es Dropbear, que no se ve afectado, salvo que el administrador haya instalado openssh-server.
OpenSSH describe la solución en 10.6p2 como una medida paliativa: ahora sshd rechaza una coincidencia cuando el campo almacenado en /etc/shadow tiene menos de cuatro caracteres. El proyecto atribuye la causa principal a comportamientos fuera de sshd (la implementación de crypt() en musl) y advierte sobre la rapidez de publicación del arreglo tras recibir el informe.
No se han reportado ataques en la naturaleza vinculados con este fallo en el momento de la publicación.
Lee también:
- IA, seguridad en la nube y respuesta a incidentes, las habilidades más buscadas en ciberseguridad
- Informe semanal de vulnerabilidades de WordPress: resumen de las novedades detectadas por Wordfence (26 oct–1 nov 2026)
Fuente: The Hacker News
