SSHole (CVE-2026-123158): Bypass de Autenticación en OpenSSH sobre musl libc

Resumen Ejecutivo

CVE-2026-123158 (SSHole) es una vulnerabilidad de bypass de autenticación en OpenSSH que permite a un atacante remoto iniciar sesión sin contraseña válida en cuentas cuyo acceso debería estar bloqueado. Sin embargo, su explotación no es universal: requiere que cinco condiciones específicas se cumplan simultáneamente en el sistema objetivo.

⚠️ Sistemas afectados: Servidores Linux con musl libc (como Alpine Linux) ejecutando OpenSSH sin PAM.
Versión corregida: OpenSSH 10.6p2

---

¿Qué es SSHole?

SSHole es el nombre con el que la comunidad de ciberseguridad ha bautizado la vulnerabilidad CVE-2026-123158. El fallo reside en cómo sshd (el daemon de OpenSSH) verifica contraseñas cuando opera sin PAM en sistemas que utilizan musl libc como biblioteca estándar de C.

La causa raíz

El problema se origina en una colisión de significados del carácter *:

1. En /etc/shadow, el marcador * en el campo de contraseña significa: "esta cuenta no tiene contraseña utilizable".
2. Cuando musl libc no puede procesar un hash (por ejemplo, si la entrada excede su límite), su función crypt() devuelve * como indicador de error.

Sin PAM, sshd compara el resultado de crypt() con el valor almacenado en /etc/shadow. Si ambos son *, la comparación resulta en una coincidencia falsa y el sistema concede acceso.

---

Las 5 Condiciones Simultáneas

Para que SSHole sea explotable, todas estas condiciones deben cumplirse al mismo tiempo:

#	Condición	Detalle	Cómo verificarla
1	Biblioteca C	Linux con musl libc (no glibc)	ldd --version o revisar enlazado del binario
2	Sin PAM	UsePAM no o paquete sin soporte PAM	sshd -T | grep usepam
3	Contraseñas habilitadas	PasswordAuthentication yes	sshd -T | grep passwordauthentication
4	Cuenta objetivo con *	Campo shadow exactamente *	Revisar /etc/shadow (requiere root)
5	Cuenta donante con hash válido	Otra cuenta con hash $5$ o $6$	Revisar /etc/shadow

💡 Clave: Si falta cualquiera de estas cinco condiciones, la vulnerabilidad no es explotable.

---

Análisis Técnico del Flujo de Ataque

El bypass sigue este flujo cuando las 5 condiciones se cumplen:

[Atacante] → Envía contraseña larga a sshd
       ↓
[sshd] → Toma la sal de otra cuenta (hash válido $5$ o $6$)
       ↓
[musl crypt()] → No puede procesar la entrada → Retorna "*"
       ↓
[sshd] → Compara "*" (retorno de crypt) con "*" (campo shadow)
       ↓
[Resultado] → Coincidencia falsa → ACCESO CONCEDIDO ❌

OpenSSH 10.6p2 corrige el problema rechazando hashes almacenados demasiado cortos antes de que la comparación pueda ocurrir.

---

Impacto Real

¿Qué puede hacer un atacante?

Si se cumplen todas las condiciones, el atacante obtiene:

• Acceso remoto sin credenciales a cuentas supuestamente bloqueadas
• Nivel de privilegio correspondiente a la cuenta comprometida
• Potencial de movimiento lateral dentro de la infraestructura
• Establecimiento de persistencia si la cuenta tiene permisos de escritura

¿Qué sistemas NO están afectados?

• Sistemas con glibc (Ubuntu, Debian, RHEL, CentOS, Fedora)
• Servidores con PAM habilitado (UsePAM yes)
• Configuraciones con autenticación solo por claves (PasswordAuthentication no)
• Cuentas sin el marcador * en /etc/shadow

---

Detección

Paso 1: Verificar si tu sistema es vulnerable

Ejecuta estos comandos con privilegios de administrador:

# Revisar configuración efectiva de sshd
sshd -T | grep -Ei 'passwordauthentication|usepam|permitrootlogin|allowusers'

# Buscar cuentas con marcador "*" y posibles hashes donantes
awk -F: '($2=="*" || $2 ~ /^\$[56]\$/){print $1 ":" $2}' /etc/shadow

⚠️ La salida de la segunda consulta contiene información sensible. Protégela adecuadamente.

Paso 2: Buscar evidencia de explotación

Revisa los logs de autenticación en busca de accesos inesperados:

# Alpine Linux / BusyBox
grep 'Accepted password' /var/log/messages

# Sistemas con journald
journalctl -u sshd | grep 'Accepted password'

Si encuentras accesos por contraseña para cuentas que solo deberían usar claves, o cuyo campo shadow contiene *, tienes un indicador de posible compromiso.

---

Mitigación: Plan de Acción

🔴 Acción inmediata (si no puedes actualizar ahora)

Deshabilitar la autenticación por contraseña:

# Editar /etc/ssh/sshd_config
PasswordAuthentication no

# IMPORTANTE: Verificar que tienes acceso por claves antes de reiniciar
ssh -i /ruta/a/tu/clave usuario@servidor

# Reiniciar sshd
rc-service sshd restart  # Alpine Linux

🟢 Solución definitiva

# Alpine Linux
apk update && apk upgrade openssh-server

# Verificar la versión instalada
ssh -V
# Debe mostrar OpenSSH_10.6p2 o superior

# Reiniciar el servicio
rc-service sshd restart

Checklist post-mitigación

• Paquete OpenSSH actualizado a 10.6p2 o parche del proveedor
• Servicio sshd reiniciado tras la actualización
• Verificada la versión activa contra el aviso de la distribución
• Revisados logs de autenticación en busca de accesos sospechosos
• Auditadas cuentas con marcador * en /etc/shadow
• Documentado el estado de remediación

---

Conclusión

SSHole (CVE-2026-123158) demuestra cómo un indicador de error puede convertirse en una decisión de autenticación válida cuando se combinan componentes y supuestos incompatibles. La respuesta adecuada no es catalogar todo sistema Alpine o musl como comprometido, sino:

1. Verificar las cinco condiciones acumulativas
2. Actualizar el paquete corregido de la distribución
3. Reiniciar el servicio sshd
4. Revisar los registros de autenticación

La buena noticia: la conjunción de las cinco condiciones necesarias limita significativamente la superficie de ataque real. Pero si tu infraestructura las cumple, la actualización es prioritaria.

---

Artículo del laboratorio de inteligencia en ciberseguridad de Cybervantax. Información verificada con fuentes oficiales.