Síntesis
Una vulnerabilidad presente desde 2016 permite acceder a cuentas que no deberían aceptar contraseñas en servidores Linux que usan la biblioteca musl y no utilizan PAM. El CSIRT Nacional advirtió que podría afectar seriamente a servicios esenciales, mientras Alpine Linux ya publicó paquetes corregidos.
- El atacante solo necesita una conexión y el nombre de una cuenta sin contraseña.
- El CSIRT Nacional calificó la falla como crítica para operadores de importancia vital.
- La falla nace de la forma en que musl responde ante contraseñas de más de 256 bytes.
- Actualizar y reiniciar el servicio SSH, o desactivar el acceso por contraseña, cierra la brecha.
Noticia
El proyecto OpenSSH, implementación del protocolo SSH usada para acceso remoto a servidores, publicó este 5 de noviembre la versión 10.6p2 que incluye una solución crítica para sistemas Linux que usan musl libc (biblioteca base de C) con PAM (módulo de autenticación) desactivado.
Según Alpine Linux, distribución liviana basada en musl, un atacante con acceso al puerto SSH puede ingresar sin conocer ninguna contraseña. El ataque requiere una sola conexión y funciona en todos los intentos.
Para que ocurra, la cuenta atacada debe tener un asterisco en el campo de contraseña, lo normal en cuentas que solo usan llaves criptográficas. Además, otra cuenta del equipo debe tener una contraseña con hash de tipo $5$ o $6$, y el acceso por contraseña debe estar habilitado, como ocurre por defecto.
Entre las cuentas expuestas figuran root, los usuarios que solo usan llaves y los que provienen de servicios de directorio. En las imágenes oficiales de nube de Alpine, entre las versiones 3.18.11 y 3.24.3, el usuario alpine puede escalar a root mediante doas (herramienta para ejecutar comandos como administrador) sin contraseña.
El problema surge porque musl devuelve un asterisco como señal de error cuando recibe una contraseña de más de 256 bytes. Como las cuentas sin contraseña almacenan ese mismo símbolo, el sistema interpreta que ambos coinciden y autoriza el acceso.
El comportamiento se combina con un cambio de 2016 en OpenSSH. Ese ajuste respondía a CVE-2016-6210, una falla reportada por el investigador Eddie Harari que permitía averiguar qué usuarios existían enviando contraseñas largas.
OpenSSH aclaró que “consideramos que la causa raíz de este error está fuera de sshd”. Aun así, la nueva versión bloquea esa vía de explotación.
La falla fue reportada por el especialista Özgün Kültekin, de la empresa Wakefield. El investigador probó 17.600 inicios de sesión en distintas compilaciones, y solo la combinación de musl sin PAM aceptó accesos indebidos.
Para Fernando Lagos, CEO de NIVEL4, la alerta debe leerse con calma. “Si bien es crítica, se tienen que cumplir una serie de requisitos y no todos los sistemas Linux están afectados. Si tienes servidores con CentOS, RHEL o Ubuntu, no estás afectado”, explicó.
El especialista precisa que la falla afecta a sistemas Linux más livianos, como Alpine, usados a menudo en contenedores y dispositivos con pocos recursos. “Si usas Docker con instancias Alpine, probablemente no estés afectado. Generalmente una imagen Docker no trae OpenSSH”, agregó.
Tras la publicación de la falla, el CSIRT Nacional de la Agencia Nacional de Ciberseguridad (ANCI) emitió la alerta AVC26-00747, que la calificó como crítica. Según el organismo, podría afectar seriamente a sistemas de proveedores de servicios esenciales y operadores de importancia vital, e involucra a OpenSSH 10.6p1 y versiones anteriores.
El CSIRT recomendó actualizar de inmediato a OpenSSH 10.6p2. Alpine corrigió el problema en sus versiones 3.21.10, 3.22.8, 3.23.8 y 3.24.4, y publicó parches hasta la 3.16, aunque esas ramas ya no tengan soporte. Tras actualizar, hay que reiniciar sshd, ya que el servicio en ejecución no se reemplaza solo.
En declaraciones recogidas por The Hacker News, Damien Miller, del proyecto OpenSSH, pidió a quienes no puedan actualizar “configurar PasswordAuthentication=no o deshabilitar SSH en estos sistemas INMEDIATAMENTE”.
Para detectar intrusiones, Alpine recomienda revisar el registro /var/log/messages en busca de accesos con contraseña a cuentas que no la tienen. “Si no puede descartar un inicio de sesión, trate la máquina como comprometida”, advirtieron. Hasta ahora no hay ataques reportados ni identificador CVE asignado.
