FortiBleed 2026: cuando la VPN se convierte en la puerta de entrada

Tabla de contenido

El 7 de junio de 2026 Fortinet confirmó lo que los investigadores de seguridad llevaban semanas documentando: una campaña de compromiso masivo contra dispositivos FortiGate que dejó 75.000 equipos afectados en 194 países. El ataque combinó una vulnerabilidad de autenticación SAML (CVE-2026-24858, CVSS 9.8) con un fallo en cómo FortiOS almacenaba las contraseñas durante el proceso de actualización. El resultado: 1.160 millones de intentos de autenticación en 29 días, credenciales de administrador en manos de actores de amenaza y acceso directo a redes corporativas a través de las mismas VPN diseñadas para protegerlas.

Este artículo analiza qué falló técnicamente, por qué el vector de ataque era predecible y cómo un stack de autenticación bien configurado —en particular FreeRADIUS con MFA— reduce drásticamente el radio de explosión de este tipo de incidente.

Qué ocurrió: el ataque explicado
#

CVE-2026-24858 es un bypass de autenticación en FortiCloud SSO a través del canal SAML. Un atacante con acceso de red al portal de gestión puede construir una aserción SAML manipulada que el dispositivo acepta como válida sin verificar la firma correctamente. El resultado es sesión de administrador sin credenciales.

El segundo vector, más sutil, explica por qué la campaña tuvo tanta escala de extracción de credenciales. Los archivos de configuración de FortiGate incluyen un campo old-password que conserva el hash de la contraseña anterior durante el proceso de migración entre versiones. Los dispositivos actualizados a FortiOS 7.2.11+, 7.4.8+ o 7.6.1+ —que cambiaron de SHA-256 a PBKDF2— guardaban el hash SHA-256 en ese campo hasta el siguiente cambio de contraseña manual. Un atacante que extrae el backup de configuración obtiene un hash SHA-256 sin sal, craqueable offline con hardware moderno en minutos para contraseñas débiles o comunes.

# Extracto típico de config comprometida (estructura anonimizada)
config system admin
    edit "admin"
        set password ENC <hash-PBKDF2>
        set old-password <SHA256-sin-sal>   ← vector de craqueo offline
    next
end

La cadena de ataque completa:

Explotación de CVE-2026-24858 → acceso administrador vía SAML bypass
Extracción del backup de configuración
Craqueo offline del hash SHA-256 del campo old-password
Reutilización de credenciales: VPN SSL, FortiCloud, Active Directory si el administrador reutilizaba contraseña

Escala real: entre el 19 de mayo y el 7 de junio, se registraron ataques contra más de 320.000 dispositivos FortiGate expuestos a internet. El 23% de ellos —75.000— quedaron comprometidos.

Dónde falla el modelo “VPN como perímetro”
#

FortiBleed no es excepcional. Es la demostración más reciente de un patrón conocido: los dispositivos de perímetro concentran privilegio de acceso y son objetivos de alto valor. Un dispositivo FortiGate comprometido equivale a llaves de la red entera.

El problema estructural es la autenticación de factor único en la VPN. Si el acceso VPN SSL solo requiere usuario y contraseña, comprometer esa contraseña (ya sea por craqueo de hash, phishing o credential stuffing) es suficiente para acceder a la red interna. La VPN se convierte en una puerta con una sola llave.

MFA en el acceso VPN convierte este ataque en un proceso de dos pasos que requiere comprometer simultáneamente la contraseña y el factor temporal. Para la mayoría de los atacantes, el segundo factor rompe la cadena de ataque aunque las credenciales estén expuestas.

FreeRADIUS + TOTP como backend MFA para FortiGate
#

La solución no requiere licencias adicionales de Fortinet. FortiGate soporta autenticación RADIUS nativa y puede delegar el factor adicional a un servidor FreeRADIUS que combine pam_winbind (credenciales AD) con pam_google_authenticator (TOTP de 6 dígitos).

La arquitectura resultante:

Usuario → FortiGate SSL-VPN
           ↓ RADIUS (PAP)
     FreeRADIUS 3.x
           ↓ PAM
    pam_google_authenticator   ← verifica TOTP
    pam_winbind                ← verifica contraseña AD
           ↓
    Active Directory

El usuario introduce ContraseñaAD123456 —contraseña seguida del OTP de 6 dígitos— como un string único. FreeRADIUS separa los factores y valida cada uno independientemente. Si el hash SHA-256 de la contraseña AD queda expuesto en un ataque similar a FortiBleed, el atacante aún necesita el código TOTP rotativo para acceder a la VPN.

Configuración PAM mínima funcional
#

# /etc/pam.d/radiusd
auth required pam_google_authenticator.so \
    forward_pass \
    secret=/etc/google-authenticator/${USER} \
    user=freerad
auth required pam_winbind.so use_first_pass
account required pam_winbind.so

forward_pass pasa la contraseña AD (sin el OTP ya consumido) al módulo siguiente. use_first_pass evita pedir la contraseña de nuevo. user=freerad es crítico: sin él, pam_google_authenticator intentará hacer setuid y el proceso fallará con el usuario freerad que corre FreeRADIUS.

Activar Auth-Type PAP en el virtual server
#

# /etc/freeradius/3.0/sites-enabled/default
authorize {
    preprocess
    update control {
        &Auth-Type := PAP
    }
    pam
}

authenticate {
    Auth-Type PAP {
        pam
    }
}

Sin el bloque update control, FreeRADIUS no sabrá que debe delegar en PAM y rechazará todas las peticiones con No Auth-Type found: rejecting via Post-Auth-Type = Reject.

Los errores que aparecen durante la implementación
#

Configurar este stack genera errores específicos que aparecen sistemáticamente. Los siete más frecuentes —con causa exacta y solución— están documentados en detalle en el artículo Errores frecuentes en FreeRADIUS 3.x con PAM: guía de diagnóstico.

Resumen de los puntos más críticos relacionados con la seguridad:

Permisos del directorio TOTP: si /etc/google-authenticator/ pertenece a root, el proceso freerad no puede crear el fichero temporal que previene replay attacks. El síntoma es Failed to create tempfile: Permission denied. La solución es chown freerad:freerad /etc/google-authenticator/.

Permisos de los ficheros de secreto: pam_google_authenticator rechaza ficheros con permisos 0644 por razones de seguridad. La autenticación falla silenciosamente desde la perspectiva de FreeRADIUS. Solo visible con freeradius -X. Solución: chmod 600 /etc/google-authenticator/*.

Contraseñas en logs: el módulo auth_log registra atributos sensibles independientemente de auth_badpass = no. Si está habilitado en la sección authorize, las contraseñas aparecerán en los logs aunque la configuración diga lo contrario.

Medidas de remediación inmediata ante FortiBleed
#

Si tienes dispositivos FortiGate en producción, las acciones prioritarias son:

1. Actualizar FortiOS

FortiOS 7.2.x → 7.2.11 o superior
FortiOS 7.4.x → 7.4.8 o superior
FortiOS 7.6.x → 7.6.1 o superior

2. Rotar credenciales de administrador después de actualizar

El campo old-password se limpia en el siguiente cambio de contraseña. Sin este paso, el hash SHA-256 vulnerable permanece en el backup de configuración incluso después del parche.

3. Habilitar protección contra hashes débiles

config system global
    set login-lockout-upon-weaker-encryption enable
end

4. Verificar si el dispositivo fue comprometido

# Buscar accesos SAML anómalos en los logs
grep "SAML" /var/log/fortios-forticloud.log | grep -E "login|session"

# Verificar cambios de configuración recientes
get system status | grep "Last configuration change"

5. Implementar MFA en la VPN SSL

Este es el cambio estructural que convierte futuras vulnerabilidades de contraseña en ataques incompletos. Con FreeRADIUS + TOTP, un atacante con la contraseña AD no puede acceder a la VPN sin el código temporal del segundo factor.

El patrón de fondo
#

FortiBleed sigue el mismo patrón que CVE-2024-21762 (Fortinet SSL-VPN path traversal), Citrix Bleed (CVE-2023-4966) y el compromiso masivo de Pulse Secure de 2021: los dispositivos de perímetro concentran acceso y son objetivos prioritarios precisamente por eso.

La respuesta técnica es doble: mantener el firmware actualizado (reducir la ventana de exposición de vulnerabilidades conocidas) e implementar defensa en profundidad en la autenticación (garantizar que comprometer una capa no equivale a comprometer el acceso completo).

FreeRADIUS con MFA es una capa de defensa que no depende de que el fabricante del perímetro publique el parche a tiempo. Existe el stack, está documentado y es gratuito.

Para la implementación completa del stack FreeRADIUS + PAM + pam_google_authenticator + pam_winbind, consulta la serie de artículos sobre infraestructura MFA empresarial en este blog.

Qué ocurrió: el ataque explicado#

Dónde falla el modelo “VPN como perímetro”#

FreeRADIUS + TOTP como backend MFA para FortiGate#

Configuración PAM mínima funcional#

Activar Auth-Type PAP en el virtual server#

Los errores que aparecen durante la implementación#

Medidas de remediación inmediata ante FortiBleed#

El patrón de fondo#