- OpenSSH soluciona un fallo crítico en servidores Linux: las contraseñas largas permitían saltarse la autenticación
- Detectan un fallo en APT que permite ejecutar código como root en Debian y Ubuntu
Varios atacantes han empezado a explotar SSHole, el fallo de OpenSSH que permite saltarse la autenticación en ciertas configuraciones Linux. El SANS Internet Storm Center detectó los primeros intentos claros el 5 de noviembre, con contraseñas kilométricas hechas de caracteres repetidos. El problema solo afecta a servidores que combinan la biblioteca musl libc con la ausencia de PAM, aunque quien cumpla esas condiciones corre un riesgo real.
Johannes Ullrich, investigador de SANS, registró en sus honeypots Cowrie 232 peticiones con contraseñas formadas por la letra «A» repetida el 5 de noviembre, cifra que subió a 713 al día siguiente. La actividad se remonta al 1 de noviembre, aunque Ullrich cree que esos primeros intentos eran scripts de fuerza bruta mal hechos, no una explotación deliberada de SSHole, y que algunos colaron comandos de descarga en el propio campo de contraseña.
Las direcciones IP más activas en el escaneo fueron 213.86.169.133, 152.233.50.185 y 92.255.57.7, con 48, 44 y 43 intentos respectivamente. Cowrie solo guarda los primeros 255 caracteres de cada contraseña, así que los investigadores no pueden examinar del todo las entradas más largas. Ullrich sospecha que algún inicio de sesión contra el honeypot llegó a tener éxito, aunque su informe no confirma sesiones abiertas: las cifras de SANS miden peticiones sospechosas, no compromisos confirmados ni atacantes distintos entre sí, porque una misma dirección puede repetir el ataque varias veces.
Algunas fuentes aseguran haber confirmado acceso root en un honeypot con Alpine Linux, citando el identificador CVE-2026-123158 en una publicación del 6 de noviembre. Ese hallazgo apunta a que la explotación funciona en la práctica dentro de entornos controlados, aunque SANS mantiene la cautela sobre el alcance real en servidores de producción expuestos en internet. Desde INCIBE, el Instituto Nacional de Ciberseguridad, han alertado de este problema.
Estas son las condiciones que dejan expuesto a un servidor OpenSSH
El investigador Özgün Kültekin destapó SSHole, y vamos a explicarte las condiciones exactas que lo hacen posible: hace falta que OpenSSH corra sobre la biblioteca musl libc, que la comprobación de contraseñas se haga sin pasar por PAM (el sistema de inicio de sesión de Linux) y que la autenticación por contraseña esté activada. Además, la cuenta a la que se quiere acceder debe tener el campo de contraseña marcado con un asterisco, y tiene que existir otra cuenta local con un hash SHA-crypt válido.
El mecanismo es sencillo una vez se conoce: cuando la contraseña supera los 256 bytes, la función crypt() de musl puede devolver un asterisco como señal de error. OpenSSH compara ese asterisco con el que tiene guardado la cuenta objetivo y, al coincidir, deja pasar el inicio de sesión. El rango de ataque documentado va de 257 a 1.024 bytes. Las cuentas con un hash de contraseña válido no se pueden saltar por esta vía, y StepSecurity ha comprobado que activar PAM bloquea el ataque por completo.
Parchear, mitigar y vigilar los logs: así se cierra la puerta a SSHole
La solución llegó con OpenSSH 10.6p2, que corrige el fallo de raíz. Alpine ya ha publicado los paquetes parcheados para sus repositorios: lo lógico es instalar la actualización de tu distribución y reiniciar sshd en cuanto puedas. Revisa la revisión exacta del paquete, porque algunos backports mantienen el banner de la versión antigua de OpenSSH aunque el fallo ya esté corregido por debajo, un detalle que te recomendamos verificar.
Si por lo que sea no puedes actualizar todavía, existe una mitigación rápida: configurar PasswordAuthentication no en el servidor cierra esta vía de ataque sin tocar nada más. Hay que valorarlo con cuidado si todavía tienes usuarios que entran con contraseña en lugar de clave SSH, porque dejarán de poder autenticarse hasta que migren a un par de claves.
También merece la pena revisar los registros de acceso de tus propios servidores. Busca inicios de sesión con contraseña que hayan tenido éxito en cuentas que, en teoría, solo deberían aceptar claves SSH, sobre todo cuando varios intentos fallidos van seguidos de una aceptación dentro de la misma sesión. Las 713 peticiones que Ullrich contabilizó el 6 de noviembre, frente a las 232 del día anterior, confirman que el volumen de escaneos se disparó justo después de conocerse el fallo. Asegúrate siempre de configurar OpenSSH con la máxima seguridad.