Vulnerabilidad de SSH en Alpine Linux permite iniciar sesión sin contraseña mediante cadenas largas
Un error crítico en el servidor OpenSSH de Alpine permite a los atacantes iniciar sesión sin contraseña enviando cadenas de tamaño excesivo a cuentas que no tienen contraseña definida.
Traducido automáticamente del original en inglés.
Alpine Linux ha emitido una advertencia de seguridad urgente por una vulnerabilidad grave en su implementación del servidor OpenSSH. El fallo permite a los atacantes remotos eludir por completo la autenticación por contraseña y obtener acceso de shell a los sistemas afectados sin conocer ninguna credencial. Los administradores que ejecutan versiones de Alpine desde la 3.16 hasta la 3.24 deben actualizar sus paquetes openssh y reiniciar inmediatamente el demonio SSH para cerrar esta exposición.
Qué ocurrió
La vulnerabilidad afecta al demonio sshd cuando se compila sin Módulos de Autenticación Conectables (PAM), que es la configuración predeterminada del paquete estándar openssh-server de Alpine. Un atacante que pueda acceder al puerto SSH puede iniciar sesión como cualquier cuenta de usuario que no tenga contraseña definida, siempre que el sistema tenga al menos otra cuenta local con un hash de contraseña estándar. El ataque requiere solo un intento de conexión y tiene éxito de forma fiable sin reintentos ni técnicas de fuerza bruta.
Este problema afecta a una amplia gama de lanzamientos de Alpine, incluidas las versiones compatibles 3.21 a 3.24 y versiones anteriores no compatibles hasta la 3.16. Apunta específicamente a sistemas donde PasswordAuthentication está habilitado, lo cual sigue siendo el valor predeterminado de OpenSSH a menos que se deshabilite explícitamente. Los escenarios comunes incluyen cuentas root configuradas con PermitRootLogin yes, usuarios de solo clave creados sin contraseñas y usuarios gestionados mediante servicios de directorio como SSSD o Winbind que carecen de entradas locales en shadow.
Las imágenes oficiales tiny-cloud son particularmente vulnerables si han sido modificadas después del arranque inicial. Aunque estas imágenes vienen con valores predeterminados seguros, añadir cualquier usuario con un hash de contraseña o establecer una contraseña de consola introduce la condición necesaria para la explotación. Una vez activado, un atacante puede iniciar sesión como el usuario predeterminado alpine y escalar privilegios a root usando doas, que está configurado para uso sin contraseña en estos entornos.
Cómo funciona
La causa raíz radica en cómo OpenSSH maneja la verificación de contraseñas cuando se compila sin soporte PAM. En este modo, sshd utiliza la función de biblioteca C crypt() para generar el hash de la contraseña proporcionada y compararla con el hash almacenado en /etc/shadow. Para las cuentas sin contraseña, el campo almacenado contiene un único asterisco (*). Normalmente, crypt() requiere una sal del hash almacenado para procesar la entrada, pero las cuentas con * no tienen sal.
Al encontrar dicha cuenta, sshd toma prestada la sal de otra cuenta en el sistema que sí tenga un hash válido $5$ o $6$. La vulnerabilidad se activa cuando el atacante envía una cadena de contraseña de entre 257 y 1024 bytes de longitud. La biblioteca C musl, utilizada por Alpine, devuelve * como indicador de error al procesar claves más largas de 256 bytes. Dado que el campo almacenado para la cuenta objetivo también es *, la comparación coincide y la autenticación tiene éxito.
Detalles clave
- Versiones afectadas: Alpine 3.16 a 3.24, incluyendo edge y lanzamientos no compatibles.
- Requisitos previos:
sshdcompilado sin PAM (oUsePAM no),PasswordAuthentication yesy al menos una cuenta con un hash$5$o$6$. - Cuentas objetivo: Usuarios con
*en el campo de contraseña, como usuarios de solo clave o el usuario predeterminadoalpine. - Paquetes corregidos: Disponibles para todas las ramas, incluyendo 9.9_p2-r1 para 3.21 y 10.6_p2-r0 para edge.
- Detección: Compruebe
/var/log/messagesbuscando entradasAccepted password forvinculadas a cuentas sin contraseña. - Riesgo en la nube: Las imágenes tiny-cloud se vuelven explotables si se añade cualquier hash de contraseña después del arranque.
Por qué importa
Para ingenieros de infraestructura y equipos DevOps, esta vulnerabilidad socava la suposición fundamental de que las cuentas SSH de solo clave son seguras frente a ataques basados en contraseña. Muchas organizaciones dependen de Alpine para contenedores y VMs ligeras, asumiendo a menudo que deshabilitar el inicio de sesión con contraseña de root es suficiente. Sin embargo, este error evade esas protecciones explotando la interacción entre campos de contraseña vacíos y la presencia de otros hashes de contraseña en el sistema. Destaca los riesgos de las configuraciones predeterminadas en distribuciones mínimas donde no se usa PAM.
La facilidad de explotación hace que esto sea especialmente peligroso. A diferencia de los ataques de fuerza bruta que generan ruido y pueden ser bloqueados por fail2ban, este método requiere solo un paquete y no deja rastros inmediatos de intentos fallidos. Si un atacante obtiene acceso a una instancia en la nube, puede escalar rápidamente privilegios y moverse lateralmente dentro de la red. Los equipos deben verificar no solo que han actualizado los paquetes, sino que el demonio en ejecución se haya reiniciado realmente, ya que los gestores de paquetes no siempre reinician los servicios automáticamente.
Qué puedes hacer
- Actualice su sistema inmediatamente usando
apk upgrade -U -ay asegúrese de instalar la versión corregida para su rama. - Reinicie el demonio SSH explícitamente con
rc-service sshd restartdespués de actualizar, ya que la actualización sola no recarga el proceso en ejecución. - Si no puede actualizar inmediatamente, deshabilite la autenticación por contraseña estableciendo
PasswordAuthentication noen su configuración SSH y reinicie el servicio. - Verifique su configuración con
sshd -T | grep -i passwordauthenticationpara asegurarse de que el cambio esté activo. - Audite sus registros buscando entradas inesperadas
Accepted passwordpara cuentas que no deberían tener contraseñas. - Revise las instancias en la nube para detectar cualquier hash de contraseña de usuario añadido que pudiera haber habilitado inadvertidamente la vulnerabilidad.



