Ivanti Connect Secure: cómo la omisión de autenticación y el RCE convirtieron una VPN en punto de entrada

Desde el 10 de enero de 2024, los gateways afectados de Ivanti Connect Secure e Ivanti Policy Secure debían aplicar la mitigación publicada por Ivanti y, una vez disponible la corrección, instalarla. El motivo se indicó de forma directa: CVE-2023-46805 y CVE-2024-21887 se explotaban en conjunto, lo que permitía a un atacante remoto omitir la autenticación y ejecutar comandos arbitrarios en el dispositivo.

El alcance práctico de ese requisito va más allá de instalar la corrección. Cuando se publicó el boletín, la explotación ya estaba en curso, y Volexity documentó los web shells, las modificaciones de archivos y la actividad posterior al acceso inicial halladas en gateways VPN comprometidos. Por eso conviene separar dos tareas: cerrar la vía vulnerable y determinar si esa vía ya había sido utilizada.

Qué se veía desde fuera antes del ataque

El primer elemento de la cadena fue un gateway VPN accesible desde internet. No se trata de un indicio colateral ni de una consecuencia del compromiso: la accesibilidad remota es la función de ese tipo de nodo. En el ataque descrito por Volexity, el objeto de la explotación fue un Ivanti Connect Secure que aceptaba conexiones externas.

Este es el paso que podía verse antes de la intrusión. Para detectarlo no hacían falta registros del dispositivo, indicadores de compromiso ni información sobre las acciones del atacante. Bastaba con constatar que el servicio VPN estaba publicado en el perímetro externo y que correspondía a un producto para el que Ivanti había informado de la explotación activa de dos vulnerabilidades.

Lectura práctica: una línea en el inventario de activos que diga que existe una VPN no responde por sí sola a la pregunta sobre el riesgo. Hace falta confirmar que el gateway es realmente accesible desde fuera en el momento actual. Esa distinción importa para los dispositivos que pudieron publicarse después del inventario, devolverse a la red o quedar accesibles en una dirección que el registro no asocia con el propietario esperado.

De ahí la relación con el control del perímetro externo. El escaneo continuo primero encuentra el servicio accesible desde internet, y la priorización por explotabilidad lo separa del resto de los sistemas detectados: Ivanti indicó que CVE-2023-46805 y CVE-2024-21887 se usaron en ataques reales. Aquí la prioridad no la define únicamente la gravedad de cada defecto por separado, sino la combinación de tres condiciones: el servicio es accesible desde internet, las vulnerabilidades forman una cadena operativa y la explotación está confirmada.

Paso 1. Omisión de la autenticación

CVE-2023-46805 afecta al componente web de Ivanti Connect Secure e Ivanti Policy Secure. Según la descripción de Ivanti, la vulnerabilidad permite a un atacante remoto omitir las comprobaciones de autenticación y acceder a recursos restringidos.

Es la primera transición de la cadena. El acceso a la página de inicio de sesión no equivale por sí mismo a un acceso administrativo. CVE-2023-46805 cambiaba esa condición: una solicitud podía alcanzar un recurso que, en el modelo previsto, debía estar protegido por una verificación de identidad.

Lectura práctica: la autenticación multifactor de los usuarios de la VPN no rompe la cadena descrita. La vulnerabilidad estaba en el componente web del propio gateway y permitía omitir su comprobación de autenticación. No es una conclusión sobre la inutilidad de la protección multifactor en general, sino el límite de su aplicabilidad en este incidente: un control a nivel de usuario no sustituye la corrección de un defecto en el dispositivo que implementa ese control.

Paso 2. Ejecución de comandos

CVE-2024-21887 es una vulnerabilidad de inyección de comandos en los componentes web de los mismos productos. En la descripción de Ivanti, su explotación requiere acceso administrativo autenticado.

Por separado, ese requisito reduce la accesibilidad de la vulnerabilidad para un atacante externo. En la cadena deja de ser una barrera: CVE-2023-46805 permite omitir la autenticación y, a continuación, CVE-2024-21887 hace posible ejecutar comandos. Ivanti describe el resultado de la cadena como la ejecución de comandos arbitrarios sin autenticación.

Esto explica por qué evaluar cada CVE de forma aislada resulta insuficiente. El requisito de autenticación de CVE-2024-21887 podría parecer una condición compensatoria. CVE-2023-46805 elimina precisamente esa condición. Para priorizar en el perímetro externo, la unidad de evaluación debe ser el par de vulnerabilidades sobre un mismo gateway accesible, y no dos entradas independientes en una lista.

Paso 3. Actividad en el gateway

Con la ejecución de comandos disponible, el atacante pasó de explotar vulnerabilidades a operar dentro del dispositivo. Volexity detectó ejecución de comandos, recopilación de datos y modificaciones en los sistemas comprometidos. El informe describe además la instalación de web shells y la modificación de archivos del gateway.

En esta fase la VPN ya no puede considerarse solo un medio para transportar tráfico hacia los recursos internos. El código se ejecutaba en el propio dispositivo de borde. Por lo tanto, la verificación posterior debe abarcar no solo las conexiones de los usuarios a través de la VPN, sino también el estado del sistema de archivos, la configuración y los componentes del gateway.

Lectura práctica: bloquear con éxito las solicitudes posteriores a la ruta vulnerable no responde a la pregunta de si en el dispositivo permanece un mecanismo de acceso instalado con anterioridad. Cerrar la entrada inicial y eliminar sus consecuencias pertenecen a etapas distintas de la respuesta.

Paso 4. Persistencia

Volexity describió los web shells instalados en equipos Ivanti Connect Secure comprometidos. Un mecanismo así cambia la lógica del acceso posterior: el atacante ya no necesita recorrer de nuevo la cadena inicial de vulnerabilidades si el componente dejado en el dispositivo sigue aceptando comandos.

Aquí es donde deja de sostenerse la fórmula «se instaló el parche, el incidente está cerrado». La corrección debe eliminar la vía vulnerable. No demuestra que esa vía no se usara antes de su instalación, ni constituye por sí misma el resultado de una verificación del estado del dispositivo.

En las recomendaciones de Ivanti, la verificación de compromiso está separada de la aplicación de la mitigación y de las correcciones. Para esa verificación se proporciona la Integrity Checker Tool; cuando se detectan indicios de compromiso, Ivanti señala la necesidad de restaurar el dispositivo a su estado de fábrica antes de devolverlo a producción y aplicar las correcciones.

Alcance práctico: la ausencia de explotación posterior de las CVE tras instalar el parche no es un resultado negativo de la investigación. Se necesita una base independiente para considerar limpio el gateway. Para un dispositivo ya afectado, esa base no puede ser únicamente un nuevo nivel de correcciones.

Dónde la cadena se rompía a menor costo

El punto de control más temprano estaba antes de la primera solicitud del atacante: detectar un Ivanti Connect Secure accesible desde internet y relacionarlo con el par de vulnerabilidades explotadas activamente. En esa fase no hacía falta buscar web shells ni restaurar el dispositivo. Hacía falta reducir el tiempo entre la publicación de la información de Ivanti y la aplicación de la mitigación o la corrección prescritas.

El punto siguiente es la verificación del gateway después del aviso de explotación. Resulta más costoso, porque implica buscar rastros y admite la restauración del dispositivo. Aun así, sigue rompiendo la cadena antes de que el acceso conservado se tome por el estado normal de un sistema ya corregido.

La monitorización de los cambios en el perímetro externo responde a un riesgo distinto. Una verificación puntual muestra que el gateway era accesible en el momento de la comprobación. No revela que el dispositivo volviera después a la red ni que se publicara de nuevo. Si una VPN aparece hacia el exterior después de una campaña de correcciones, para ella vuelve a darse la condición inicial de la cadena: un servicio accesible desde internet cuyo estado hay que contrastar con el requisito vigente de Ivanti.

También conviene fijar el límite de la conclusión. El escaneo externo muestra que existe un punto de entrada y permite determinar su prioridad. No establece la ausencia de compromiso dentro del dispositivo. De esa tarea se ocupan la verificación de integridad, el análisis de los artefactos señalados por Volexity y el procedimiento de restauración previsto por Ivanti cuando se detectan indicios de manipulación.

Dónde podía romperse la cadena

Cada requisito se presenta a continuación junto con la acción que le corresponde.

• Desde el 10 de enero de 2024: aplicar a los gateways afectados la mitigación publicada por Ivanti y después instalar la corrección disponible — encontrar todos los Ivanti Connect Secure e Ivanti Policy Secure accesibles desde internet, determinar su estado y aplicar la medida del boletín de Ivanti
• Desde el 10 de enero de 2024: tener en cuenta la explotación conjunta de CVE-2023-46805 y CVE-2024-21887 — priorizar el par accesible desde internet como una única cadena de omisión de autenticación y ejecución de comandos, en lugar de evaluar las CVE de forma aislada
• Tras detectar un gateway externo: determinar si fue comprometido antes de corregir las vulnerabilidades — ejecutar la verificación de integridad prevista por Ivanti y revisar las modificaciones y los web shells descritos por Volexity
• Si se detectan indicios de compromiso: no limitarse a instalar el parche — realizar la restauración del dispositivo al estado de fábrica prescrita por Ivanti y aplicar después las correcciones necesarias antes de devolverlo a producción
• Tras el inventario inicial: controlar los cambios de accesibilidad — hacer seguimiento de los gateways VPN nuevos y republicados y volver a contrastarlos con la información sobre explotación activa