CVE-2024-6387: regreSSHion — RCE en OpenSSH después de 18 años

Una condición de carrera en el manejador de señales de OpenSSH permite a atacantes no autenticados ejecutar código arbitrario como root en servidores Linux que ejecutan glibc. Bautizada como «regreSSHion», es una regresión de CVE-2006-5051 que se reintrodujo accidentalmente en 2020. Afecta aproximadamente a 14 millones de servidores SSH expuestos a Internet. CVSS 8.1 ALTA.

¿Qué es CVE-2024-6387?

CVE-2024-6387 es una condición de carrera en el manejador de señales del servidor de OpenSSH (sshd). Cuando un cliente no se autentica dentro del plazo de LoginGraceTime (valor predeterminado: 120 segundos), sshd llama a SIGALRM para finalizar la conexión. El manejador de señales llama a funciones que no son seguras para señales asíncronas — concretamente syslog() —, lo que puede corromper el estado del heap cuando se ejecutan simultáneamente con otras operaciones.

Los investigadores de Qualys que descubrieron la vulnerabilidad la denominaron «regreSSHion» porque un error idéntico (CVE-2006-5051) se corrigió en 2006, pero la corrección se eliminó involuntariamente cuando OpenSSH 8.5p1 se publicó en octubre de 2020, lo que significa que la vulnerabilidad volvió a existir silenciosamente durante casi cuatro años antes de ser descubierta.

Versiones afectadas

Requisito de glibc: El PoC de Qualys explotó la implementación de malloc de glibc. El sshd de OpenBSD no es vulnerable. Alpine Linux (que utiliza musl libc) y macOS no son vulnerables a la técnica de explotación demostrada, aunque la condición de carrera sigue existiendo.

Explicación de la condición de carrera

Los manejadores de señales de los programas en C solo deben llamar a funciones «seguras para señales asíncronas», un pequeño subconjunto de funciones de libc que pueden ejecutarse de forma segura desde un manejador de señales porque no utilizan estado compartido. La función syslog() no es segura para señales asíncronas porque utiliza malloc internamente.

# La ruta de código problemática (simplificada):
# Cuando LoginGraceTime vence:
SIGALRM → grace_alarm_handler() → syslog() → malloc() internamente
                                              ↕ CARRERA
           el hilo principal de sshd también llama a malloc() / free()

# Si ambas operaciones malloc se intercalan:
# → Corrupción del heap
# → Con suficientes intentos: disposición controlada del heap
# → Ejecución remota de código como root

La explotación requiere ganar la condición de carrera de forma fiable, lo que exige miles de intentos de conexión durante varios minutos. Esto hace que la explotación automatizada a escala de Internet sea algo más lenta que la de las vulnerabilidades típicas de «disparar y olvidar», pero los actores sofisticados con acceso persistente a un objetivo disponen de tiempo de sobra.

Dificultad de explotación

Qualys demostró una explotación fiable en sistemas de 32 bits (x86). En sistemas de 64 bits, ASLR aumenta considerablemente la dificultad. Los investigadores señalan que, con unos 10 000 intentos durante 6-8 horas, la explotación es teóricamente posible en sistemas de 64 bits, pero no publicaron un PoC funcional para x86_64.

Sin embargo, la dificultad puede reducirse mediante:

• Filtraciones de información que neutralicen ASLR (exploits combinados)
• Fuerza bruta en entornos donde fail2ban o la limitación de frecuencia no estén configurados
• Futuras investigaciones que mejoren la técnica de explotación
• Acceso a sistemas vulnerables de 32 bits (todavía habituales en IoT y Linux embebido)

Detección

# Comprobar la versión de OpenSSH
ssh -V
sshd -V

# Comprobar la versión del paquete instalado (Debian/Ubuntu)
dpkg -l openssh-server | grep openssh

# Comprobar la versión del paquete instalado (RHEL/CentOS)
rpm -qa | grep openssh-server

# Buscar intentos de fuerza bruta indicativos de la explotación de regreSSHion
# (frecuencia de conexión muy alta desde una sola IP, todos fallidos durante el período de gracia)
grep "Connection closed by" /var/log/auth.log | 
  awk '{print $9}' | sort | uniq -c | sort -rn | head -20

# Buscar inicios de sesión fallidos con una frecuencia alta
grep "Failed\|Invalid" /var/log/auth.log | 
  awk '{print 1}' | sort | uniq -c | sort -rn | head -10

Mitigación

1. Actualizar OpenSSH a 9.8p1 o posterior: Todas las distribuciones principales publicaron parches pocos días después de la divulgación. apt update && apt upgrade openssh-server o equivalente.
2. Establecer LoginGraceTime en 0: Configurar LoginGraceTime 0 en /etc/ssh/sshd_config impide que se llame al manejador SIGALRM, eliminando la condición de carrera (aunque también elimina el tiempo límite de gracia):

   echo "LoginGraceTime 0" >> /etc/ssh/sshd_config
   systemctl reload sshd

3. Limitar la frecuencia de las conexiones SSH: Configurar fail2ban o la limitación de frecuencia de iptables para impedir los miles de intentos de conexión necesarios para la explotación
4. Restringir el acceso SSH por IP: Limitar sshd a intervalos de IP de administración conocidos mediante AllowUsers, ListenAddress o reglas de firewall
5. Utilizar únicamente claves SSH: Desactivar la autenticación mediante contraseña; la autenticación basada en claves añade un sólido filtro previo a la autenticación
6. Considerar trasladar SSH a un puerto no estándar: Reduce el ruido de los escáneres oportunistas, aunque no constituye un control de seguridad

Capacidad de detección de KENSAI

• Escaneo de banners SSH: KENSAI identifica las versiones de OpenSSH en todos los activos expuestos a Internet y marca las versiones 8.5p1–9.7p1 como vulnerables a CVE-2024-6387
• Escaneo de redes internas: Detección exhaustiva de servidores SSH vulnerables en redes internas
• Auditoría de configuración: Comprueba la existencia de configuraciones de mitigación (LoginGraceTime, AllowUsers y autenticación únicamente mediante claves)
• Validación de parches: Confirma la aplicación del parche después de la corrección
• Contexto de exposición: Prioriza los servidores SSH expuestos a Internet frente a los sistemas exclusivamente internos