El asterisco que abre el servidor: qué hay de cierto en el fallo de OpenSSH

Hoy me ha llegado por LinkedIn un aviso con sirena incluida: OpenSSH acaba de sacar un parche de emergencia, un atacante puede entrar «a servidores Linux» sin conocer la contraseña, y debajo, una captura de alguien que escribe una ristra de aes y aparece como root.

Lo he comprobado. El fallo es real y es serio, y si administras servidores con Alpine Linux, conviene que lo mires hoy. Pero no afecta a «los servidores Linux» en general: exige una combinación concreta de biblioteca, configuración y cuentas. Y el mensaje mezcla cosas ciertas con otras que no lo son tanto.

Ilustración generada con IA para este artículo; no representa ningún servidor ni sistema real.

Vamos a separarlas.

Qué ha pasado, en orden

Qué hay de cierto en lo que circula

La captura, además, no se puede tomar como prueba. Normalmente ssh no enseña lo que escribes al pedir la contraseña, y ahí se ve entera. Y sea una demostración preparada o no, no dice cómo estaba configurado ese servidor, que es justo lo que decide si se llega a root.

Un apunte sobre la gravedad: el fallo tiene un 8,1 sobre 10 en CVSS, es decir, «alto». Como conté hace unos días al explicar qué significa que una vulnerabilidad sea crítica, la categoría de crítica empieza en el 9. OpenSSH usa la palabra en su anuncio y no le falta motivo, pero la nota es otra cosa: baja porque el ataque depende de cómo esté montada cada máquina.

¿Te afecta?

Según el aviso de Alpine, estás expuesto si se cumplen todas estas condiciones:

1. sshd funciona sobre musl y sin PAM. Es lo normal en Alpine con el paquete openssh-server. También estás en este caso con openssh-server-pam si tienes UsePAM no.
2. El acceso por contraseña está activo, que es el valor por defecto de PasswordAuthentication.
3. Hay una cuenta con exactamente * como contraseña. Es lo habitual en un usuario que solo entra con clave SSH, y root viene así en Alpine desde aproximadamente la versión 3.16.
4. Hay otra cuenta local con una contraseña de verdad, con un hash $5$ o $6$.

Fuera de Alpine, Wakefield cita también otros sistemas basados en musl: OpenWrt, postmarketOS, Void en su variante musl, Chimera y las compilaciones de Buildroot y Yocto que lo usan. Si usas alguno con OpenSSH, compruébalo con su proyecto.

Hay tres casos que merecen una línea aparte:

• Docker. Una imagen basada en Alpine no es vulnerable por serlo: lo que importa es si dentro hay un sshd funcionando y accesible. Alpine excluye los contenedores que no lo ejecutan, que deberían ser casi todos.
• Imágenes cloud de Alpine. Las tiny-cloud oficiales, de la 3.18.11 a la 3.24.3, traen un usuario alpine con * como contraseña y doas sin contraseña. Son seguras en el primer arranque, pero dejan de serlo en cuanto aparece un hash $6$ en la máquina, por ejemplo al poner una contraseña de consola. Y aquí está lo que el aviso de LinkedIn se deja: el paso de esa cuenta a root es inmediato con doas, aunque PermitRootLogin siga protegiendo a root. Las configuradas con cloud-init, que escribe PasswordAuthentication no, no están afectadas.
• Dropbear. Es otro servidor SSH, habitual en routers y sistemas embebidos, y no está afectado, tampoco en versiones antiguas. Si lees lo contrario, es porque su autor avisó el día 5 de que la 2018.76 y anteriores eran vulnerables, y rectificó horas después, cuando Rich Felker, de musl, le hizo ver que Dropbear nunca ha hecho la comprobación que causa el problema.

Qué hacer

Actualizar y reiniciar. En Alpine:

apk upgrade -U -a
rc-service sshd restart

No te fíes de ssh -V para comprobarlo: enseña la versión del cliente, no la del servidor que está en marcha. Y como las ramas estables de Alpine llevan el arreglo aplicado sobre su versión de siempre, el número de versión tampoco basta. Lo que hay que mirar es la revisión del paquete, con apk info -v | grep openssh, y compararla con la tabla del aviso de Alpine:

Si no puedes actualizar ahora, apaga el acceso por contraseña. Es lo que recomiendan Alpine, musl y Wakefield, que asegura que cierra el problema por completo. Antes, asegúrate de que puedes entrar con clave SSH, o te quedarás fuera de tu propio servidor. Mantén también abierta la sesión actual hasta comprobar que puedes abrir otra.

No basta con añadir una línea al final del archivo: puede haber otra antes que mande, o un bloque Match que lo vuelva a activar para ciertos usuarios o conexiones. Esta es la receta de Alpine, que cubre esos casos y guarda una copia del original:

mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sed -i.bak -e '1i PasswordAuthentication no' \
  -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
  /etc/ssh/sshd_config
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

La última orden debe responder passwordauthentication no. Esa respuesta es la configuración general, así que si tienes bloques Match, míralos también. De hecho, si tu servidor está en internet y todos entráis con clave, este ajuste merece quedarse aunque ya hayas actualizado.

Y si estuvo expuesto, revísalo. Actualizar cierra el agujero, pero no echa a quien haya podido entrar antes. Alpine propone buscar en /var/log/messages un Accepted password for en una cuenta que no tiene contraseña (alpine, root o cualquier usuario que solo use claves), y repasar el uso de doas, los usuarios y archivos creados hace poco y los authorized_keys.

¿Se está explotando ya?

Actualización del 9 de noviembre. Ya no hay una sola fuente. GreyNoise, otra empresa que mantiene sensores en internet, confirma explotación con éxito desde el día 7 en máquinas vulnerables que tiene desplegadas para observar estos ataques. Ha visto a los atacantes ejecutar comandos, dejar claves SSH en las cuentas alpine y root, intentar levantar un segundo sshd en el puerto 2222 e instalar un agente de control remoto que, según cuenta, no llegó a conectar con su servidor. Así que ya no son solo intentos, y si tuviste un equipo expuesto, a la revisión de arriba añade esto: mira si hay un sshd escuchando donde no toca.

Pero todas esas máquinas son suyas: sigo sin encontrar víctimas reales ni cifras de servidores comprometidos. GreyNoise tampoco explica cómo se llegó a root ni cómo tenía configurados sus sensores. Previdian ha seguido subiendo sus contadores, y en su página sigue sin decir cómo estaba montado su señuelo. La CISA no lo tenía en su catálogo de vulnerabilidades explotadas en la última versión publicada, la del 6 de noviembre. Y en musl todavía no ha cambiado nada, aunque Felker ha adelantado que, sin estar decidido, la versión 1.2.7 probablemente devolverá *0 en lugar de *, el carácter de más del que hablo abajo. Lo que sigue es lo que escribí el día 6.

Hay una sola fuente y conviene leerla con cuidado. La empresa Previdian dice que sus sensores vieron el primer intento menos de nueve horas después de publicarse el CVE, y su fundador declaró a Help Net Security que han confirmado acceso de root en un señuelo con Alpine y OpenSSH reales.

Las cifras de intentos todavía se mueven, así que no me apoyo en ninguna. Lo que sí importa es la advertencia de la página de Previdian: sus datos no demuestran que el objetivo fuera vulnerable ni que el intento tuviera éxito. Tampoco dice cómo estaba configurado el señuelo, y eso importa: para entrar directamente como root, tenía que permitirlo su configuración.

Según Help Net, la CISA estadounidense no lo tiene en su catálogo de vulnerabilidades explotadas, y no he encontrado una confirmación independiente ni cifras de servidores comprometidos. Eso no es motivo para esperar. Hay pruebas de concepto públicas desde el mismo día 5, y el propio Dewhurst lo describe como especialmente trivial de explotar, así que lo prudente es dar por hecho que alguien está probando. Previdian avisa también de que esas pruebas de concepto no están verificadas y pueden contener malware, así que mejor no ejecutar lo primero que aparezca en GitHub para ver si eres vulnerable.

Por qué ha tardado diez años en salir

Lo más interesante del caso es que no hay ninguna pieza claramente absurda. El fallo sale de tres decisiones razonables, tomadas por separado:

• Un asterisco que significa «nadie». Desde hace décadas, poner un * en el campo de la contraseña quiere decir que ninguna contraseña puede coincidir, porque un hash nunca sale así. Y sshd comprueba las contraseñas calculando el hash de lo que le mandas y comparándolo con lo guardado.
• musl, 2012. Esta biblioteca de C, la base de Alpine, decidió que crypt() devolviera * cuando falla, en lugar de NULL. Y le puso un tope de 256 bytes a la clave para evitar ataques de denegación de servicio. Las dos cosas tienen sentido.
• OpenSSH, 2016. Para que el tiempo de respuesta no delatara qué cuentas existen, sshd empezó a usar la sal de otra cuenta cuando la propia no tiene. Esto llegó en la versión 7.3p1, y por eso hace falta esa segunda cuenta con contraseña real.

Júntalas y la comparación que debía fallar siempre acaba siendo * contra *. Y coincide. La condición decisiva del arreglo de OpenSSH cabe en una línea: no dar por buena la comparación si lo guardado mide menos de cuatro caracteres, porque eso no es un hash.

He querido ver la primera mitad con mis propios ojos, así que he llamado a crypt() con claves de distinta longitud en dos contenedores desechables, sin SSH de por medio:

Debian también falla con claves muy largas, pero devuelve *0, un carácter de más que no coincide con ningún *. La cronología de su descubridor lo resume en tres palabras: «one character away», a un carácter de distancia. Debian no está a salvo solo por eso, porque usa PAM y otra biblioteca, pero la imagen vale: entre un valor que nunca coincide y otro que coincide con lo guardado hay un solo carácter.

¿Y de quién es la culpa? Nadie la quiere, y los dos argumentos son defendibles. OpenSSH dice en su anuncio que la causa de fondo está fuera de sshd, aunque se pueda evitar desde él. Rich Felker, responsable de musl, sostiene que no es un fallo de musl sino un uso erróneo por parte de quien llama a la función, aunque añade que ese mecanismo es algo que ya querían cambiar y que muy probablemente cambiará en el próximo ciclo. Mientras se discute, el arreglo ya está instalado donde podía ponerse más rápido.

Lo mío

Después de esto tocaba mirar mi casa. Esta web se desarrolla en contenedores, y tres de los cinco que levanto usan Alpine: el de PHP, el de nginx y el de correo de pruebas. Ninguno de los cinco lleva sshd, así que aquí no hay nada que hacer. Es la situación más habitual: mucho Alpine alrededor, y ningún servidor SSH dentro.

Si necesitas una mano

Si no tienes claro si alguno de tus servidores cumple estas condiciones, o quieres dejar el acceso por clave bien montado sin quedarte fuera, escríbeme. Dime qué sistema tienes y cómo entras en él, aunque no sepas más, y te digo qué hay que hacer, lo hagas tú, tu proveedor o yo.