SSHole: fallo en OpenSSH abre cuentas sin contraseña en Alpine

Un fallo de diez años en la forma en que OpenSSH y la biblioteca C musl gestionan los hashes de contraseña fallidos permite a un atacante remoto entrar en cuentas configuradas deliberadamente sin contraseña utilizable, enviando una única contraseña absurdamente larga. El fallo, identificado como CVE-2026-123158 y apodado SSHole (o *sshole), tiene una puntuación CVSS de 8,1 y se corrigió en una actualización de emergencia de OpenSSH 10.6p2 publicada el jueves. Lo descubrió Ozgun Kultekin, investigador de la firma de pruebas de seguridad Wakefield, según CSO Online.

Sería una nota al pie si no afectara a musl. Pero musl es la biblioteca C detrás de Alpine Linux, la distribución minimalista que sustenta gran parte de las imágenes Docker en la nube, además de una larga cola de sistemas embebidos. La compilación predeterminada de OpenSSH en Alpine cumple todas las condiciones del exploit de serie, y sus imágenes oficiales en la nube incluyen el usuario alpine sin contraseña, con privilegios doas sin contraseña: un paso para escalar a root. Y la explotación no es teórica: la firma de inteligencia de amenazas Previdian dijo a The Hacker News que observó el primer intento de ataque menos de nueve horas después de publicarse el CVE, y confirmó acceso root exitoso en un honeypot con Alpine.

La primitiva: 257 caracteres de cualquier cosa

Jake Knott, responsable de inteligencia de amenazas en watchTowr, lo expresó sin rodeos en declaraciones a CSO Online: el exploit de un fallo en algo tan extendido como OpenSSH no es más que enviar una contraseña larga; una cadena de caracteres A bastará. En los sistemas afectados, dijo, toda la técnica consiste en una contraseña de entre 257 y 1.024 caracteres.

Eso es todo el ataque. Sin condiciones de carrera, sin manipulación del heap, sin shellcode, y según Ars Technica, funciona en una sola conexión, siempre, sin reintentos. Compárese con regreSSHion de 2024, el último gran susto de OpenSSH, que exigía verdadera ingeniería de exploits; SSHole requiere una cadena de A copiada y pegada. Lo que categóricamente no puede hacer es saltarse una contraseña real: como señala The Hacker News, el fallo solo se activa en cuentas cuyo campo de contraseña es un asterisco, así que las cuentas con hashes de contraseña válidos son inmunes a este truco concreto.

Tres cambios inocentes, un asterisco fatal

El fallo es un accidente de integración de sistemas formado por tres cambios hechos con años de diferencia, cada uno defendible por separado. En 2012, los desarrolladores de musl limitaron la longitud de contraseña a 256 bytes para que los atacantes no pudieran saturar los servidores enviando contraseñas enormes que requerían un hash costoso. Al mismo tiempo, hicieron que la función de hash de contraseñas de musl devolviera un asterisco (*) siempre que fallara, y el asterisco es exactamente el carácter que Unix usa desde los años ochenta para marcar cuentas en las que ninguna contraseña debería coincidir jamás.

En 2016, OpenSSH corrigió un fallo de enumeración de nombres de usuario (CVE-2016-6210) tomando prestada la sal de otra cuenta al verificar contraseñas de cuentas cuyo propio campo no ofrece nada contra lo que calcular el hash, una corrección pensada para impedir que los atacantes adivinaran nombres de usuario válidos por diferencias de tiempo. Luego, en 2022, Alpine cambió el campo de contraseña de root a un asterisco para que los inicios de sesión SSH con clave siguieran funcionando para esa cuenta. Al juntar las tres piezas, la cadena se monta sola: un atacante envía una contraseña de 257 o más bytes para una cuenta sin contraseña, el intento de hash de musl falla y devuelve *, sshd compara eso con el * almacenado en el campo de contraseña de la cuenta, coinciden, y la puerta se abre.

$ ssh alpine@target        # password: 300 x 'A'
# musl crypt() fails on >256 bytes -> returns "*"
# /etc/shadow stores "*" for the alpine account
# "*" == "*"  ->  sshd logs: Accepted password for alpine

Para constancia, los mantenedores de OpenSSH sostienen que el fallo no está en su código, sino en el manejo de errores de musl, pero aun así incluyeron una mitigación en 10.6p2. Desde la perspectiva del defensor, la disputa de culpabilidades importa menos que el parche.

Qué está expuesto y qué no

Deben cumplirse cinco condiciones para que SSHole funcione, y la lista sirve también como checklist de alcance:

• La distribución está basada en musl, no en glibc, lo que excluye a Debian, Ubuntu, Fedora y la mayoría de distribuciones de servidor convencionales.
• El servidor SSH es OpenSSH, no una alternativa como Dropbear (común en compilaciones embebidas).
• OpenSSH se compiló sin soporte de PAM; el paquete estándar de Alpine se construye exactamente así.
• La autenticación por contraseña está habilitada, de nuevo el valor predeterminado de Alpine.
• El atacante conoce el nombre de una cuenta con un asterisco en su campo de contraseña, y existe al menos una cuenta con contraseña real (con hash SHA256/SHA512) en el sistema.

Esta última condición, señalada por Ars Technica, tiene una implicación delicada para las imágenes oficiales en la nube de Alpine. Entre las versiones 3.18.11 y 3.24.3, esas imágenes incluyen la cuenta alpine sin contraseña con doas sin contraseña, pero solo se vuelven explotables cuando un administrador establece una contraseña para cualquier otra cuenta, porque debe existir una cuenta legítima con hash real para que se active la ruta de código de la sal prestada. En cuanto alguien hace esa rutinaria configuración, la imagen queda abierta de par en par, y el inicio de sesión de alpine se convierte directamente en root. Otras plataformas basadas en musl podrían verse afectadas bajo la misma configuración, según Ars. Kultekin ha publicado en GitHub un script de comprobación que identifica servidores expuestos y enumera las cuentas en riesgo: ejecútalo antes de tu ventana de cambios, no después.

Explotación: confirmada en un honeypot, esperada en todas partes

Esto es lo confirmado, y es limitado: Previdian observó ocho intentos de explotación desde una única dirección IP, 89.116.89[.]18, geolocalizada en Japón, y confirmó que los atacantes lograron root en un honeypot con Alpine Linux y OpenSSH. «La IP de origen observada, 89.116.89[.]18, usó contraseñas sobredimensionadas para eludir la autenticación y ejecutó comandos de reconocimiento como id, uname y hostname mediante sesiones SSH no interactivas», dijo Ryan Dewhurst, fundador y CEO de Previdian, en una declaración a The Hacker News.

Un acierto en un honeypot no es prueba de compromiso empresarial, pero la economía sugiere asumir una pulverización masiva. El punto de Knott es que los servidores SSH expuestos a internet ya soportan intentos de adivinación de contraseñas y fuerza bruta las 24 horas, y explotar SSHole requiere solo añadir una contraseña muy larga a una lista de fuerza bruta existente; watchTowr se sorprendería mucho si los atacantes de fuerza bruta no lo intentaran en cuestión de días. Safe Security, por su parte, señaló lo que viene después del inicio de sesión: «Aunque el acceso SSH no autorizado es el impacto inmediato, los atacantes también pueden obtener credenciales de despliegue, secretos de aplicaciones e infraestructura conectada, lo que podría permitir el movimiento lateral o la interrupción del servicio».

Detección: busca el inicio de sesión imposible

SSHole deja una huella maravillosamente ruidosa: una autenticación por contraseña exitosa para una cuenta que no tiene contraseña. Una línea "Accepted password" en /var/log/messages para root, el usuario alpine o cualquier cuenta solo con clave es, según CSO Online, un fuerte indicio de compromiso, porque ese evento no debería ser posible en un sistema sano. El aviso del propio Alpine, según informó The Hacker News, pide a los defensores buscar en /var/log/messages entradas de sshd que muestren una contraseña aceptada para una cuenta que no la tiene (la cuenta alpine, root o cualquier usuario solo con clave), y revisar el uso de doas junto con los usuarios creados recientemente, archivos y claves autorizadas en las máquinas expuestas. La conclusión del aviso: si no puedes descartar un inicio de sesión, trata la máquina como comprometida.

Aunque el acceso SSH no autorizado es el impacto inmediato, los atacantes también pueden obtener credenciales de despliegue, secretos de aplicaciones e infraestructura conectada, lo que podría permitir el movimiento lateral o la interrupción del servicio. — Safe Security, citado por The Hacker News

Una advertencia para tu búsqueda: como musl trunca cualquier cosa por encima de 256 bytes antes de calcular el hash, los intentos maliciosos pueden no parecer exóticos en los registros; el resultado de la autenticación sí. Alerta sobre el éxito imposible, no sobre la longitud de la contraseña.

Mitigación y el elefante con forma de contenedor en la habitación

La solución en sí es sencilla: instala OpenSSH 10.6p2 o el paquete openssh parcheado de tu distribución (Alpine ha publicado actualizaciones de emergencia) y reinicia sshd. Si no puedes parchear esta semana, el workaround recomendado por Alpine es desactivar por completo la autenticación por contraseña y pasar al inicio de sesión basado en clave:

# /etc/ssh/sshd_config — the workaround Alpine recommends if you can't patch
PasswordAuthentication no
# then set up key-based auth and restart sshd

El trabajo más difícil es el inventario. Parchear tus servidores y dar el asunto por cerrado deja sin ver el radio de impacto real, porque la huella real de Alpine es su imagen base de contenedor. Cualquier imagen derivada de una versión afectada de Alpine que ejecute sshd, por depuración, por herramientas de despliegue heredadas o por razones que nadie recuerda, es una posible puerta abierta, y la mayoría de organizaciones no tienen una lista fiable de cuáles de sus contenedores en ejecución contienen siquiera un demonio SSH. Es la misma clase de problema que vimos con un fallo CVSS 10 en LXD y MicroCloud que permitió la suplantación de clientes de confianza: la infraestructura de contenedores hereda silenciosamente supuestos de confianza que nadie revisó de nuevo.

Así que la solución a largo plazo es una cuestión de pipeline, no de parches. Revisa tus registros y pods en ejecución en busca de binarios sshd, reconstruye todo lo basado en el rango afectado de imágenes cloud de Alpine desde una base parcheada, y plantéate la incómoda pregunta de por qué un contenedor necesita un servidor SSH interactivo. Los ecosistemas basados en Alpine ya han demostrado ser frágiles bajo presión: un RCE por regex en GitLab entró en el catálogo KEV de CISA tras un ataque a infraestructura Alpine, y un bypass de autenticación de diez años que necesita una contraseña desmesuradamente larga es exactamente el tipo de fallo que las botnets de fuerza bruta absorben en sus diccionarios y nunca eliminan. Parchea rápido, busca en tus registros inicios de sesión que no deberían existir y trata como comprometido cualquier host en el que no puedas descartarlo. Esa última parte es el consejo del propio Alpine, y es la paranoia correcta.