La historia de cómo `*`, que en 1980 impidió la entrada a todo el mundo, se convirtió en una llave 46 años después

En 1980, Bill Joy, el desarrollador de Unix, puso un asterisco (*) en la contraseña de la cuenta daemon, en la que nadie debería iniciar sesión. En aquel entonces, los hashes de contraseñas también se guardaban en el archivo /etc/passwd, que era legible por cualquier usuario, pero el * no es un hash de contraseña válido, por lo que no coincide con ninguna contraseña y funciona como un dispositivo que bloquea el inicio de sesión de forma inherente. En el campo de nombre real (real name) de esa misma entrada, estaba escrito "the devil himself" ¹.

Sin embargo, en 2026, ese * se ha convertido, curiosamente, en una llave que "permite el acceso si se introduce cualquier texto de entre 257 y 1024 caracteres". La vulnerabilidad 'sshhole' revelada por el investigador que la descubrió se produce cuando la lógica de defensa contra ataques de temporización —que intenta ocultar la información de la cuenta mediante diferencias en la velocidad de respuesta del servidor— coincide accidentalmente con el límite de longitud de contraseña de la biblioteca musl de Linux ². Aparece especialmente en entornos ligeros como Alpine Linux u OpenWrt que no utilizan PAM (módulo de autenticación conectable). Este problema ha sido corregido en la versión OpenSSH 10.6p2 (distribuida el 5 de noviembre de 2026) ³.

El proceso en que el * se convierte en una llave: el choque de tres reglas

La vulnerabilidad sshhole surge cuando tres mecanismos de seguridad, creados en momentos y con propósitos distintos, se encuentran en una sola línea de comparación. Cada mecanismo era válido en sí mismo, pero su combinación permitía eludir la autenticación.

1. Cambio en el valor de retorno de fallo en la biblioteca musl (2012): musl, una de las bibliotecas estándar de C, modificó la función crypt() (que calcula el hash de la contraseña) para que, en caso de fallo, devolviera * en lugar de NULL. Esta medida pretendía evitar que el programa se cerrara cuando los desarrolladores no gestionaban el valor NULL. Dado que un hash de contraseña normal tiene un formato como $6$salt$hash, los desarrolladores asumieron que * no coincidiría con ninguna contraseña real ².

2. Introducción del límite de longitud de 256 caracteres (2012): En la misma época, musl impuso un límite de longitud de 256 bytes para el cálculo del hash SHA-512. Como las contraseñas más largas aumentan el tiempo de cálculo, esta restricción buscaba evitar que entradas muy largas ocuparan durante demasiado tiempo al servidor, afectando a otras conexiones. Si la entrada supera los 256 caracteres, no se realiza ningún cálculo y se devuelve inmediatamente el valor de fallo * ².

3. Defensa contra ataques de temporización en OpenSSH (2016): OpenSSH cambió su lógica para evitar ataques de temporización, en los que los hackers podían descubrir información de cuentas porque las respuestas a intentos de conexión con una 'cuenta inexistente' eran más rápidas (CVE-2016-6210). Originalmente, si se intentaba iniciar sesión en una cuenta sin hash (como *), la conexión se rechazaba inmediatamente; pero tras la corrección, se tomó prestada la 'sal (número aleatorio de seguridad) de otra cuenta' para calcular un hash virtual como si se calculara un hash real, y luego se hacía fallar la autenticación ².

Punto de choque: Si se intenta iniciar sesión en una cuenta marcada con * mediante una contraseña de 257 a 1024 caracteres, la autenticación se pasa siguiendo este flujo. No obstante, para que esta elusión funcione, primero debe haberse producido un historial de fallo con una contraseña incorrecta de longitud normal ².

1. OpenSSH determina que, como el valor guardado es *, no es posible calcular un hash real.
2. Para mantener la coherencia temporal, toma prestada la sal de otra cuenta e intenta calcular un hash con la contraseña de 257 caracteres introducida por el usuario.
3. Dado que el servidor utiliza la biblioteca musl, devuelve * como resultado del cálculo para entradas que superan los 256 caracteres.
4. El servidor procesa el éxito de la autenticación porque el 'resultado calculado (*)' coincide en cadena de caracteres con el 'campo de contraseña guardado (*)' ².

Condiciones confirmadas mediante 17.600 pruebas

Esta vulnerabilidad no aparece en todos los servidores. El investigador que gestiona sshhole.com y que hizo público este problema creó varias compilaciones de OpenSSH combinando las bibliotecas glibc y musl, el uso o no de PAM y la configuración del archivo shadow. Al realizar aproximadamente 17.600 intentos de inicio de sesión anómalos, confirmó que esta autenticación elusiva solo tiene éxito en las compilaciones que "utilizan la biblioteca musl y desactivan PAM" ².

La mayoría de las distribuciones Linux convencionales (Debian, Ubuntu, Fedora, etc.) utilizan el módulo de autenticación PAM. Cuando el campo de contraseña es *, PAM rechaza la autenticación sin llegar a invocar la función de cálculo de hash (crypt()), por lo que en entornos habituales no se está expuesto a esta vulnerabilidad. Además, los entornos de prueba del propio proyecto OpenSSH se centran en OpenBSD y glibc, lo que hizo que esta combinación particular de 'musl + PAM desactivado' no se validara durante mucho tiempo ².

La amenaza real de las imágenes en la nube de Alpine

La vulnerabilidad sshhole es motivo de especial preocupación porque las imágenes en la nube oficiales de Alpine Linux (en AWS, Azure, etc.) cumplen estas condiciones por defecto.

En versiones anteriores a 2019, Alpine tenía un problema en el que la cuenta root tenía la contraseña vacía, permitiendo iniciar sesión con una contraseña en blanco (CVE-2019-5021). Para solucionarlo, se cambió el campo de contraseña a !; sin embargo, en entornos sin PAM, configurar ! tenía el efecto secundario de bloquear también la autenticación basada en claves SSH. Como consecuencia, a partir de la versión Alpine 3.16 (2022), el campo de contraseña se restableció a * para permitir el inicio de sesión mediante claves ², ⁴.

Las imágenes en la nube oficiales de Alpine en su estado por defecto tienen configurados PasswordAuthentication yes e UsePAM no. Además, la cuenta alpine generada por defecto está configurada para poder usar doas (herramienta de elevación de privilegios) sin contraseña. Por tanto, un atacante puede iniciar sesión en la cuenta alpine mediante una cadena arbitraria de 257 a 1024 caracteres y obtener inmediatamente privilegios root mediante el comando doas, sin necesidad de autenticación adicional ².

Métodos inmediatos de respuesta y revisión

La vulnerabilidad sshhole se ha corregido oficialmente en la versión OpenSSH 10.6p2 (distribuida el 5 de noviembre de 2026) ³.

1. Actualización La medida más segura es actualizar OpenSSH a la versión 10.6p2 o superior. En Alpine Linux, se puede actualizar mediante el siguiente comando:

apk upgrade openssh

2. Cambio de configuración Si no es posible actualizar, se debe desactivar la autenticación mediante contraseña. Se añade el siguiente contenido al archivo de configuración como /etc/ssh/sshd_config.d/00-no-passwords.conf:

PasswordAuthentication no

Tras cambiar la configuración, en Alpine Linux es necesario reiniciar el servicio SSH con el comando rc-service sshd restart para que surta efecto ².

3. Verificación de intrusiones Para comprobar si el servidor ya ha sido comprometido, es preciso revisar los registros del servidor. Si existen registros de inicios de sesión exitosos con el método de 'autenticación por contraseña' para cuentas cuyo campo de contraseña es exactamente *, se debe estudiar la posibilidad de que esta vulnerabilidad haya sido explotada ².