viernes, 6 de noviembre de 202617°General Pico · 13° / 20°Dólar Oficial $1.570Dólar Blue $1.555Dólar MEP $1.588Dólar Tarjeta $2.041
Alpine Linux corrige una falla en OpenSSH que permite entrar sin contraseña
Alpine Linux publicó un aviso por una vulnerabilidad en el servidor OpenSSH que permite a un atacante iniciar sesión sin conocer ninguna clave. Ya hay paquetes corregidos, pero hay que reiniciar el servicio después de actualizar.
Redacción PicoTecno
3 min de lectura
El proyecto Alpine Linux advirtió, según informó en su sitio oficial alpinelinux.org, sobre una falla en el servidor OpenSSH (sshd, el programa que recibe las conexiones remotas por SSH) que permite eludir la autenticación por contraseña. Un atacante que logre llegar al puerto SSH de una máquina vulnerable puede entrar con una sola conexión, sin reintentos y con éxito en todos los casos. Al momento de la publicación todavía no se había asignado un identificador CVE.
Para explotar el problema, el atacante necesita el nombre de una cuenta cuyo campo de contraseña sea "*", algo normal en usuarios que solo ingresan con clave criptográfica. Además, el equipo tiene que tener al menos otra cuenta con una contraseña guardada con hash de tipo $5$ o $6$. Con esas condiciones, el atacante envía una contraseña muy larga, de entre 257 y 1024 bytes. Alpine aclara que alcanza con un solo usuario con contraseña para dejar al alcance a todas las cuentas que no la tienen.
Por qué ocurre
Cuando sshd se compila sin PAM (el sistema de módulos de autenticación de Linux), verifica la clave aplicando la función crypt() del lenguaje C, que convierte una contraseña en su hash, y compara el resultado con lo almacenado. Si el campo guardado es demasiado corto para contener una sal (el prefijo aleatorio del hash), sshd toma prestada la de otra cuenta. Por su parte, la función crypt() de musl, la biblioteca de C que usa Alpine, devuelve "*" como indicador de error cuando la clave supera los 256 bytes. Como "*" es justamente lo que figura en las cuentas sin contraseña, la comparación coincide y el acceso se concede.
Los lanzamientos Alpine 3.21.10, 3.22.8, 3.23.8 y 3.24.4 incluyen el paquete corregido. También hay versiones corregidas para las ramas anteriores, hasta la 3.16, aunque la 3.21 terminó su período de soporte el 1 de noviembre de 2026. Según el aviso, están afectadas todas las versiones revisadas, de la 3.21 a la 3.24 y edge, además de las más viejas que ya no reciben actualizaciones regulares (3.16 a 3.20). El proyecto remite a las notas de OpenSSH 10.6p2 para los detalles técnicos.
La recomendación es actualizar con apk upgrade -U -a y reiniciar el servicio con rc-service sshd restart, porque instalar el paquete no reemplaza el proceso que ya está en ejecución. Quien no pueda actualizar todavía debería, como mínimo, desactivar el ingreso con contraseña con PasswordAuthentication no en la configuración de sshd y reiniciar el servicio. Cualquiera de las dos medidas cierra la brecha. Antes de aplicar cambios, Alpine sugiere confirmar que el acceso por clave funciona y mantener abierta la sesión actual hasta probar un nuevo ingreso.
El aviso también menciona un caso particular: las imágenes oficiales tiny-cloud (qcow2, VHD y AMI) de las versiones 3.18.11 a 3.24.3 incluyen un usuario "alpine" con campo de contraseña "*" y doas (herramienta para ejecutar comandos con privilegios) sin clave. Son seguras en el primer arranque, pero quedan expuestas apenas existe un hash $6$ en el equipo, por ejemplo si un administrador define una contraseña de consola o si los datos de usuario agregan un usuario con contraseña con hash. En ese caso, el atacante obtiene una sesión como "alpine" y puede convertirse en root con doas.
Para detectar posibles intrusiones, Alpine indica revisar en /var/log/messages las líneas de sshd que digan "Accepted password" para cuentas sin contraseña, como alpine, root o cualquier usuario que use solo claves. También recomienda inspeccionar el uso de doas y los usuarios, archivos y claves autorizadas creados recientemente. Si no se puede descartar un ingreso, el equipo debe considerarse comprometido. La falla fue reportada por Özgün Kültekin, de Wakefield, y la corrigieron Damien Miller y Darren Tucker, del proyecto OpenSSH, con la versión 10.6p2.
