Alpine Linux: fallo de OpenSSH permite acceso sin clave

El fallo que permite entrar a un servidor Alpine sin contraseña

Un atacante con acceso de red al puerto SSH de un servidor Alpine Linux mal configurado puede iniciar sesión sin conocer ninguna contraseña: le basta con enviar una contraseña de más de 256 caracteres. Los mantenedores de Alpine lo describieron sin matices en su aviso: «Un atacante que pueda alcanzar tu puerto SSH puede iniciar sesión sin saber ninguna contraseña. Requiere una sola conexión, funciona siempre y no necesita reintentos».

Para un founder, el dato relevante no es la rareza técnica del fallo, sino dónde vive Alpine: es una de las distribuciones base más usadas en contenedores y en imágenes cloud por su tamaño reducido. Si tu equipo construye sobre imágenes Alpine —o sobre OpenWrt, Buildroot o Yocto—, esto es una tarea de hoy, no de la próxima revisión trimestral.

¿Cómo funciona la vulnerabilidad bautizada *sshole?

El fallo no está en una línea de código, sino en la interacción entre tres piezas: OpenSSH, la librería que implementa las conexiones SSH; musl, la alternativa ligera a libc que usa Alpine en lugar de glibc; y la ausencia de PAM, el framework de autenticación que Alpine no incluye por defecto en su paquete openssh-server.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

La cadena es la siguiente:

Una cuenta del sistema tiene su contraseña deshabilitada con un asterisco (*) en /etc/shadow. Es el patrón habitual en cuentas que solo se autentican con certificado o clave SSH.
Otra cuenta del mismo equipo tiene un hash real, del tipo $5$ o $6$ (SHA256 o SHA512). Ese hash es la pieza que habilita el ataque: como la cuenta sin contraseña no tiene sal propia, sshd toma prestada la sal de la otra. Checkpoint lo explicó así: «importa porque sshd toma prestada la sal de esa cuenta. Sin eso, el ataque falla».
Sin PAM, sshd verifica la contraseña por su cuenta usando crypt(). La versión de musl devuelve * cuando el hash falla, y falla si la contraseña supera los 256 bytes.
El * que devuelve el error coincide con el * guardado en /etc/shadow. sshd interpreta la coincidencia como un login válido.

El rango útil va de 257 a 1.024 bytes, el límite que impone el propio sshd. Los investigadores de Checkpoint también comprobaron que la cuenta debe estar activa: no basta con que exista el hash.

El origen es antiguo y está documentado. Un cambio en musl del 9 de agosto de 2012 hizo que una llamada fallida a crypt() devolviera un hash no comparable en lugar de NULL, porque muchos programas no comprobaban el error; el límite de 256 bytes llegó el 29 de agosto de 2012 para protegerse de ataques de denegación de servicio. El préstamo de sal nació el 15 de julio de 2016, cuando OpenSSH modificó su comportamiento para tapar CVE-2016-6210, un fallo que permitía enumerar nombres de usuario válidos. El investigador Özgün Kültekin, que reportó el problema, sitúa ahí el inicio de la vulnerabilidad.

¿Qué sistemas están expuestos y cuáles quedan fuera?

La exposición depende de la combinación de configuración, no de la distribución en abstracto. Alpine publicó un aviso con cuatro condiciones que deben cumplirse a la vez:

Se ejecuta el paquete openssh-server, construido sin PAM, o openssh-server-pam con UsePAM no.
PasswordAuthentication está en yes, que es el valor por defecto de OpenSSH.
Existe una cuenta con * en su campo de contraseña.
Al menos otra cuenta local tiene un hash que empieza por $5$ o $6$ .

Basta una sola cuenta con contraseña para exponer a todas las que no la tienen. Además de Alpine, Kültekin señala en su análisis técnico a OpenWrt, Buildroot y Yocto como otros sistemas basados en musl que conviene revisar. En OpenWrt, el SSH lo gestiona Dropbear por defecto y no está afectado; el riesgo aparece solo si un administrador instaló el servidor OpenSSH.

Quedan fuera los sistemas con glibc —Debian, Ubuntu, Fedora—, los que autentican a través de PAM, los contenedores que no ejecutan sshd, las máquinas con PasswordAuthentication no y las cuentas bloqueadas con ! en /etc/shadow.

Hay un caso que merece atención especial: las imágenes cloud oficiales de Alpine para AWS y Azure incluyen una cuenta alpine con privilegios doas sin contraseña. Las imágenes construidas con tiny-cloud entre las versiones 3.18.11 y 3.24.3 son seguras en el primer arranque, pero quedan expuestas en cuanto aparece en el sistema cualquier hash $6$ , por ejemplo cuando un administrador define una contraseña de consola. Desde ahí, el atacante entra como alpine y escala a root con doas. La cuenta root, por sí sola, está protegida por el valor por defecto PermitRootLogin prohibit-password.

Cómo verificar y corregir tus servidores hoy

La corrección ya está disponible: OpenSSH 10.6p2 incluye el cambio que hace que sshd rechace la coincidencia cuando el campo almacenado tiene menos de cuatro caracteres. Alpine publicó paquetes corregidos para todas sus ramas desde la 3.16, incluidas las que ya estaban fuera de soporte.

Actualiza y reinicia: apk upgrade -U -a seguido de rc-service sshd restart. El reinicio es obligatorio, porque actualizar el paquete no reinicia el sshd en ejecución.
Los point releases 3.21.10, 3.22.8, 3.23.8 y 3.24.4 ya traen el paquete corregido.
Si no puedes actualizar de inmediato, desactiva el login por contraseña con PasswordAuthentication no. Antes de aplicarlo, comprueba que tu acceso por clave funciona y mantén abierta la sesión actual hasta confirmar un login nuevo. Valida con sshd -t y reinicia el servicio.
Busca señales de explotación en los logs: grep "Accepted password" /var/log/messages. Si aparece un login por contraseña en una cuenta que no debería permitirlo —alpine, root o un usuario solo con clave—, revisa también el uso de doas, los usuarios creados recientemente y las claves autorizadas. El aviso de Alpine es tajante: «Si no puedes descartar un login, trata la máquina como comprometida».

¿Qué significa esto para tu startup?

Tres decisiones concretas, aplicables esta semana:

Haz inventario de tus imágenes base. No solo de las que construyes: también de las que heredas de terceros. Una imagen Alpine antigua en un pipeline de CI/CD puede reintroducir el problema en cada build.
Separa las cuentas sin contraseña de los privilegios. El daño real no viene del login, viene de lo que puedes hacer después. Revisa qué cuentas con * en /etc/shadow tienen doas o sudo y quítales ese privilegio si no es imprescindible.
Deja de exponer SSH a internet. Un bastión o una VPN eliminan la superficie de ataque de raíz, y son más baratos que una respuesta a incidentes.

La señal de fondo: la IA encontró el bug

Kültekin descubrió la vulnerabilidad usando agentes de IA que ejecutaron alrededor de 17.600 pruebas de autenticación con distintas configuraciones de OpenSSH, hashes malformados y contraseñas sobredimensionadas. Es un cambio en el ritmo de la seguridad ofensiva que Damien Miller, del proyecto OpenSSH, ya tiene interiorizado: dijo que su equipo considera peligrosos los embargos largos porque los agentes de IA vuelven a encontrar los mismos errores, a veces en cuestión de horas.

Hasta la fecha de publicación no se había asignado un identificador CVE al fallo y no se reportaron ataques que lo explotaran. Eso no lo vuelve inofensivo: el aviso de Alpine indica que el ataque funciona en todos los intentos con una sola conexión.

Conclusión

El fallo sshole es un recordatorio incómodo de que la seguridad de una startup no se decide en el firewall, sino en la configuración por defecto de las piezas que nadie revisa: la librería C, el paquete de SSH, la cuenta sin contraseña que alguien creó hace tres años. La corrección está disponible y es simple. Lo que no es simple es saber cuántas imágenes y servidores tienes corriendo con esa configuración. Empieza por ahí.