Ivanti Connect Secure (2024): La Cadena que No Para
Análisis técnico de las vulnerabilidades encadenadas en Ivanti Connect Secure: CVE-2024-21887 (command injection) + CVE-2023-46805 (auth bypass), más CVE-2024-21893 (SSRF) y CVE-2024-22024. Cómo UNC5221 (APT chino) explotó la cadena desde diciembre 2023, por qué CISA ordenó desconectar todos los appliances, y por qué el integrity checker fue inútil.
La VPN que se convirtió en la puerta trasera
El 10 de enero de 2024, Ivanti reveló dos vulnerabilidades zero-day en su producto Connect Secure (anteriormente Pulse Connect Secure), el gateway VPN utilizado por miles de organizaciones gubernamentales y empresariales a nivel global. Lo que siguió fue un desastre que se desarrolló en cámara lenta durante semanas: más vulnerabilidades descubiertas, el integrity checker del propio Ivanti demostrado como ineficaz, los sistemas de CISA (la agencia de ciberseguridad de EE.UU.) comprometidos a través de sus propios appliances Ivanti, y una directiva de emergencia ordenando a todas las agencias federales desconectar sus dispositivos.
La cadena de vulnerabilidades de Ivanti Connect Secure es más que un incidente de seguridad. Es un caso de estudio sobre el fracaso sistémico de los appliances de red como modelo de seguridad perimetral: código propietario que no se puede auditar, herramientas de integridad que no detectan compromisos, factory resets que no eliminan la persistencia, y una cascada de vulnerabilidades donde cada parche revela un nuevo problema.
Las vulnerabilidades: una cadena interminable
CVE-2023-46805: authentication bypass por path traversal
La primera vulnerabilidad es un bypass de autenticación que explota una debilidad en cómo Ivanti Connect Secure procesa las URLs.
El componente web del appliance implementa controles de acceso basados en la ruta de la URL. Ciertos endpoints de la API REST requieren una sesión autenticada, mientras que otros (como la página de login) son accesibles sin autenticación. La vulnerabilidad explota una discrepancia entre cómo el sistema de control de acceso normaliza la URL y cómo el endpoint final la interpreta.
Mediante secuencias de path traversal (el clásico ../ pero con variantes de codificación que evaden la normalización), el atacante construye una URL que:
- El módulo de control de acceso interpreta como una ruta pública (no requiere auth)
- El enrutador de la API interpreta como un endpoint protegido
El resultado es acceso no autenticado a endpoints de la API REST que normalmente requieren credenciales de administrador.
CVE-2024-21887: command injection en la API REST
La segunda vulnerabilidad es una inyección de comandos clásica en uno de los endpoints de la API REST. Este endpoint, diseñado para tareas administrativas, procesa parámetros de entrada del usuario y los incorpora a comandos del sistema operativo sin sanitización adecuada.
Cuando se accede legítimamente (con autenticación), este endpoint solo está disponible para administradores. Pero gracias al auth bypass de CVE-2023-46805, cualquier atacante externo puede alcanzar este endpoint sin credenciales.
La cadena completa
1. El atacante envía una petición HTTP al appliance Ivanti Connect Secure
2. La URL contiene una secuencia de path traversal que evade
el control de acceso (CVE-2023-46805)
3. La petición alcanza el endpoint vulnerable de la API REST
sin autenticación
4. Los parámetros de la petición contienen una inyección de comando
(CVE-2024-21887)
5. El appliance ejecuta el comando como root
6. El atacante tiene RCE pre-auth con máximos privilegios
La explotación requiere una sola petición HTTP. No deja artefactos obvios en los logs de acceso (más allá de la petición en sí). Y proporciona acceso root al appliance, lo que significa control total sobre el gateway VPN.
CVE-2024-21893: SSRF en el componente SAML
Como si dos vulnerabilidades no fueran suficientes, Ivanti reveló una tercera el 31 de enero de 2024. CVE-2024-21893 es un Server-Side Request Forgery (SSRF) en el componente SAML de Ivanti Connect Secure.
El componente SAML procesa respuestas XML de proveedores de identidad. Una vulnerabilidad en el parser XML permitía a un atacante incluir entidades externas (XXE) que forzaban al appliance a realizar peticiones HTTP a destinos arbitrarios. En el contexto de un appliance de red con acceso tanto a Internet como a la red interna, un SSRF es especialmente peligroso.
Esta tercera vulnerabilidad podía explotarse independientemente de las dos anteriores. Un atacante podía usar el SSRF para acceder a recursos internos sin necesidad del auth bypass o la command injection.
CVE-2024-22024: otra vulnerabilidad SAML/XML
El 8 de febrero de 2024, Ivanti reveló una cuarta vulnerabilidad: CVE-2024-22024, otra vulnerabilidad XML en el componente SAML que permitía acceso a recursos restringidos sin autenticación.
A este punto, la confianza de la industria en Ivanti Connect Secure estaba en mínimos históricos. Cada parche publicado revelaba (o introducía) un nuevo problema, y la percepción era que la superficie de ataque del producto era fundamentalmente deficiente.
UNC5221: el actor detrás de la explotación zero-day
Atribución y perfil
Mandiant identificó al grupo responsable de la explotación zero-day como UNC5221, un actor de amenazas persistentes avanzadas (APT) que se cree vinculado al gobierno chino. Volexity, que investigó de forma independiente, los denominó UTA0178.
UNC5221 comenzó explotando las vulnerabilidades desde al menos diciembre de 2023, un mes antes de que Ivanti las revelara públicamente. La sofisticación de sus herramientas y tácticas indica un grupo con recursos estatales significativos y conocimiento profundo de los internals de Ivanti Connect Secure.
Arsenal de malware
El grupo desplegó un ecosistema de malware diseñado específicamente para los appliances Ivanti:
LIGHTWIRE: webshell ligera escrita en Perl que se inyectaba en un componente legítimo del appliance (el script CGI de diagnóstico). Su tamaño mínimo (pocas líneas de código) dificultaba la detección.
WIREFIRE: webshell más completa escrita en Python, desplegada como un archivo independiente en el sistema de archivos del appliance. Proporcionaba capacidades de ejecución de comandos, upload/download de archivos, y tunnel de tráfico.
BUSHWALK: webshell con funcionalidad específica de exfiltración de datos. Diseñada para extraer archivos de configuración, bases de datos de credenciales, y otros datos sensibles del appliance.
THINSPOOL: dropper especializado en persistencia. Su función principal era reinstalar las webshells después de actualizaciones del firmware o reinicios del appliance. THINSPOOL modificaba el proceso de arranque para ejecutarse automáticamente, sobreviviendo a los mecanismos normales de limpieza.
WARPWIRE: recolector de credenciales implementado en JavaScript. Se inyectaba en la página de login del appliance y capturaba las credenciales de todos los usuarios que se autenticaban, enviándolas a un servidor C2 del atacante.
ZIPLINE: el más sofisticado del arsenal. Un backdoor pasivo que interceptaba el tráfico de red del appliance, implementando capacidades de proxy inverso, tunneling de tráfico, y comunicación cifrada con servidores C2. ZIPLINE era particularmente difícil de detectar porque no abría puertos adicionales ni generaba tráfico saliente anómalo; se integraba en el flujo de tráfico legítimo del VPN.
Tácticas post-explotación
Tras obtener acceso al appliance, UNC5221 seguía un patrón operacional consistente:
- Recolección de credenciales: WARPWIRE capturaba todas las credenciales de usuarios que accedían al VPN
- Exfiltración de configuración: extraían la base de datos de configuración del appliance, que incluye credenciales de servicios backend (LDAP, RADIUS, AD)
- Establecimiento de persistencia: THINSPOOL garantizaba que las webshells sobrevivieran a actualizaciones
- Movimiento lateral: usando las credenciales recolectadas, accedían a la red interna de la organización
- Limpieza de evidencia: modificaban logs y artefactos forenses en el appliance
CISA Emergency Directive ED 24-01: desconecten todo
La directiva sin precedentes
El 19 de enero de 2024, CISA emitió la Emergency Directive (ED) 24-01, inicialmente requiriendo a todas las agencias del gobierno federal de EE.UU. que aplicaran mitigaciones a sus appliances Ivanti.
Pero la situación escaló rápidamente:
22 de enero: Volexity reporta que la explotación es "widespread", con más de 1.700 appliances comprometidos globalmente y un webshell denominado GIFTEDVISITOR encontrado en múltiples víctimas.
31 de enero: Ivanti revela CVE-2024-21893 y CVE-2024-21888. CISA actualiza ED 24-01 con mitigaciones adicionales.
1 de febrero: CISA ordena a todas las agencias federales desconectar sus appliances Ivanti de la red. No parchear. No mitigar. Desconectar completamente.
9 de febrero: Ivanti revela CVE-2024-22024. CISA advierte que el Integrity Checker Tool de Ivanti es ineficaz.
29 de febrero: CISA y sus partners internacionales publican un advisory detallado confirmando que los atacantes pueden mantener persistencia a nivel de root incluso después de un factory reset.
CISA fue víctima
En un giro particularmente significativo, se confirmó en marzo de 2024 que los propios sistemas de CISA fueron comprometidos a través de sus appliances Ivanti. La agencia encargada de proteger la ciberseguridad federal fue víctima de las mismas vulnerabilidades que estaba intentando mitigar.
CISA confirmó que dos de sus sistemas internos fueron afectados, aunque afirmó que no hubo impacto operacional y que los sistemas fueron desconectados inmediatamente. Independientemente de la magnitud real, el incidente fue un golpe simbólico para la credibilidad de las defensas perimetrales basadas en appliances.
El fracaso del integrity checker
Qué debía hacer
El Integrity Checker Tool (ICT) de Ivanti estaba diseñado para verificar que los archivos del sistema del appliance no habían sido modificados. La idea es simple: comparar los hashes de los archivos del sistema contra una lista de hashes conocidos como buenos. Si algún archivo ha sido modificado, alertar al administrador.
Por qué falló
Los investigadores de CISA descubrieron múltiples maneras en que los atacantes eludían el ICT:
-
Archivos no verificados: el ICT no verificaba todos los archivos del sistema. Los atacantes almacenaban malware en directorios y archivos que el ICT ignoraba.
-
Particiones no escaneadas: el appliance tiene múltiples particiones. El ICT solo escaneaba la partición activa, permitiendo a los atacantes almacenar herramientas en particiones alternativas.
-
Manipulación del ICT: con acceso root (obtenido via la cadena de vulnerabilidades), los atacantes podían modificar el propio ICT para que reportara que todo estaba limpio.
-
Persistencia pre-ICT: THINSPOOL se ejecutaba durante el arranque del sistema, antes de que el ICT pudiera ejecutarse. El malware podía restaurar archivos limpios antes del escaneo y reinstalar el malware después.
-
Sobrevivir al factory reset: el hallazgo más preocupante fue que los atacantes podían mantener persistencia incluso después de un factory reset del appliance. El reset no borraba todas las particiones ni todos los datos de configuración, permitiendo que el malware sobreviviera.
Las implicaciones
La ineficacia del ICT tiene implicaciones profundas para toda la industria de appliances de red:
- No se puede confiar en herramientas del propio vendor para verificar la integridad de dispositivos potencialmente comprometidos. Un atacante con acceso root puede manipular cualquier herramienta que se ejecute en el mismo sistema.
- El factory reset no es suficiente como medida de remediación para appliances comprometidos a nivel de root.
- La única remediación garantizada es el reemplazo físico del hardware o una reinstalación completa del firmware desde medios verificados externamente.
El patrón repetitivo: Pulse Secure, Citrix, Fortinet, Ivanti
Los appliances VPN y de perímetro llevan años siendo el vector de acceso inicial preferido por grupos APT y operadores de ransomware. La progresión temporal es clara:
2019: Pulse Secure VPN (CVE-2019-11510)
Vulnerabilidad de lectura arbitraria de archivos pre-auth que permitía obtener credenciales VPN directamente del appliance. Explotada masivamente por grupos de ransomware y APTs chinos. Pulse Secure fue adquirida por Ivanti en 2020.
2020: Citrix ADC (CVE-2019-19781, "Shitrix")
RCE pre-auth en Citrix NetScaler ADC/Gateway. Explotada globalmente antes de que existiera parche. El apodo "Shitrix" refleja la gravedad y la frustración de la comunidad.
2021: Fortinet FortiGate (CVE-2018-13379)
Lectura arbitraria de archivos que exponía credenciales VPN en texto plano desde archivos de log del sistema. A pesar de ser parcheada en 2019, seguía siendo explotada activamente en 2021 porque miles de organizaciones no habían actualizado.
2023: Citrix NetScaler (CVE-2023-4966, "Citrix Bleed")
Buffer over-read que filtraba tokens de sesión. LockBit lo usó contra Boeing e ICBC.
2024: Ivanti Connect Secure
La cadena documentada en este artículo. Cuatro CVEs, un integrity checker inútil, y CISA ordenando desconectar.
2024: Palo Alto PAN-OS (CVE-2024-3400)
RCE pre-auth en GlobalProtect (el componente VPN de Palo Alto Networks). Explotada como zero-day por un grupo APT. Ni siquiera el fabricante más respetado de firewalls era inmune al patrón.
¿Por qué se repite?
Los factores son estructurales:
Codebases complejas y legacy: estos productos han acumulado décadas de código. Ivanti Connect Secure hereda código de Pulse Secure, que a su vez heredó código de Juniper Networks. Cada adquisición añade complejidad sin necesariamente mejorar la calidad del código base.
Visibilidad limitada: a diferencia de endpoints convencionales (donde los EDR proporcionan telemetría detallada), los appliances de red son cajas negras. La capacidad de investigación forense es limitada, los logs son frecuentemente insuficientes, y las herramientas de monitorización estándar no se ejecutan en ellos.
Parcheo lento: actualizar un appliance VPN en producción requiere planificación. Si el appliance falla, toda la fuerza de trabajo remota pierde acceso. Esto crea una tensión entre seguridad (parchear rápido) y disponibilidad (no romper nada).
Valor máximo para el atacante: un VPN concentrator da acceso a la red interna completa y a las credenciales de todos los usuarios que se conectan. Es el punto de máximo rendimiento para cualquier atacante.
Detección y respuesta post-Ivanti
Indicadores de compromiso específicos
Webshells conocidas:
- LIGHTWIRE: modificaciones en
/dana-na/auth/cgi-bin/launchHelp.cgi - WIREFIRE: archivos Python no legítimos en
/tmp/o/data/ - BUSHWALK: archivos con extensiones inusuales en directorios de sistema
- WARPWIRE: JavaScript inyectado en la página de login (
/dana-na/auth/)
Artefactos de red:
- Conexiones salientes desde el appliance a IPs de C2 conocidas
- Tráfico DNS inusual desde el appliance
- Conexiones a la red interna desde el appliance que no corresponden a sesiones VPN legítimas
En la red interna:
- Uso de credenciales VPN desde ubicaciones geográficas anómalas
- Acceso a recursos internos desde segmentos VPN fuera del horario normal
- Herramientas de tunneling o proxy desplegadas en servidores internos
Medidas de remediación
- Desconectar el appliance de la red (no solo apagarlo; desconectar físicamente)
- Preservar evidencia forense: imagen del disco del appliance antes de cualquier intervención
- No confiar en el factory reset: el reset no garantiza la eliminación de persistencia a nivel de root
- Reemplazar o reinstalar desde medios verificados: la única remediación fiable es una instalación limpia del firmware desde medios proporcionados por Ivanti, verificando los hashes contra fuentes oficiales
- Rotar todas las credenciales: asumir que todas las credenciales de usuarios VPN, certificados, y secretos almacenados en el appliance están comprometidos
- Buscar movimiento lateral: investigar la red interna buscando indicadores de que el atacante usó las credenciales VPN para acceder a otros sistemas
- Monitorización intensiva post-remediación: los primeros 90 días tras la remediación son críticos para detectar persistencia no identificada
Hacia un modelo diferente
El incidente de Ivanti, junto con los de Citrix, Pulse Secure, Fortinet y Palo Alto, plantea una pregunta fundamental: ¿es el modelo de appliance de red perimetral viable a largo plazo?
Alternativas emergentes
Zero Trust Network Access (ZTNA): en lugar de un appliance VPN que da acceso a toda la red, ZTNA implementa acceso granular a aplicaciones específicas, verificando identidad y postura del dispositivo en cada conexión. Productos como Zscaler Private Access, Cloudflare Access, o Tailscale implementan este modelo.
Software-defined perimeter (SDP): similar a ZTNA, pero con énfasis en que los recursos internos son invisibles desde Internet hasta que un usuario autenticado solicita acceso.
Redes mesh cifradas: soluciones como WireGuard o Tailscale crean túneles punto a punto entre dispositivos, eliminando el concentrador central (y su valor como objetivo).
La realidad
La transición desde appliances VPN tradicionales es lenta. Miles de organizaciones dependen de Ivanti, Cisco, Palo Alto y Fortinet para su acceso remoto, y migrar a una arquitectura zero-trust requiere inversión significativa en infraestructura y formación. Mientras tanto, los appliances de perímetro seguirán siendo el vector de acceso inicial más atractivo para atacantes sofisticados.
La lección de Ivanti Connect Secure no es que un producto específico falló. Es que una categoría completa de productos, por su diseño arquitectónico, posición en la red, y modelo operacional, representa un riesgo sistémico que no se resuelve con parches más rápidos. Se resuelve con un modelo de seguridad fundamentalmente diferente.
Preguntas frecuentes
Artículos relacionados
Este contenido tiene fines exclusivamente educativos y de investigación en ciberseguridad defensiva. No se proporcionan binarios maliciosos ni payloads ejecutables. El uso indebido de esta información es responsabilidad exclusiva del usuario. Leer disclaimer completo.