Ir al contenido
Nuevo informe: Consiga su copia del Informe sobre el estado de Internet 2024. | Descargar hoy
Blogs

Ivanti Connect (in)Secure - Revisión

Resumen ejecutivo

  • A partir del lunes, 19 de febrero de 2024, Censys observa 24,590 pasarelas Ivanti Connect Secure expuestas
  • Más de 6.000 (casi 24.7% del total expuesto) muestran indicios de ejecutar una versión vulnerable a una o más de las cinco vulnerabilidades recientemente reveladas (CVE-2023-46805, CVE-2024-21887, CVE-2024-21888, CVE-2024-21893 y CVE-2024-22024).
  • El número de hosts potencialmente vulnerables ha disminuido en unos 7.880 casos (56.5%) desde el 31 de enero, día en que CISA publicó las medidas de mitigación actualizadas para las agencias FCEB. Tenga en cuenta que estos datos probablemente subestiman el alcance de la vulnerabilidad, ya que no todas las pasarelas Ivanti Connect Secure (ICS) anuncian sus versiones.
  • Durante esta investigación, descubrimos un número extraordinario de hosts engañosos que se hacían pasar por Ivanti Connect Secure. Estos hosts falsos estaban distribuidos por varias regiones de Amazon AWS, incluidas APAC y China específicamente.
  • Censys Search Query for exposed Ivanti Connect Secure: services.software.product: {“Connect Secure”, “connect_secure”}

Recapitulemos 

En los últimos dos meses, Ivanti ha revelado cinco vulnerabilidades diferentes que afectan a sus diversos productos, principalmente Ivanti Connect Secure y Policy Secure.

Tras nuestra cobertura de la explotación masiva de CVE-2023-46805 y CVE-2024-21887 en enero, las tres vulnerabilidades más recientes en Ivanti Connect Secure e Ivanti Policy Secure son:

  1. CVE-2024-21888 (Escalada de privilegios) - 8,8 CVSS
  2. CVE-2024-21893 (Falsificación de petición del lado del servidor) - 8.2 CVSS
  3. CVE-2024-22024 (Inyección de entidad externa XML) - 8.3 CVSS

Estas tienen puntuaciones de gravedad CVSS más bajas y no parecen plantear una amenaza tan importante como el par inicial de vulnerabilidades, pero siguen siendo motivo de preocupación.

CISA cambió finalmente su orientación para Ivanti de "aplicar mitigaciones" a "desconectar todas las instancias", y todas las agencias del Poder Ejecutivo Civil Federal (FCEB) tuvieron que desconectar sus aparatos el 9 de febrero.

Por ello, ha llegado el momento de volver a examinar si el número de dispositivos expuestos en Internet está disminuyendo.

Algo huele mal

Hemos observado algo inusual al investigar las tendencias en Ivanti Connect Secure expuestas durante las últimas semanas.

El gráfico anterior muestra que el número de hosts y servicios expuestos con Ivanti Connect Secure tenía una línea constante que rondaba los 26.000 hosts y 27.300 servicios hasta el 31 de enero, coincidiendo con el momento en que CISA emitió una actualización de su Directiva de Emergencia original.

Sin embargo, cuando volvimos a comprobar esas cifras una semana después, se dispararon a unos 41.800 hosts y unos 46.000 servicios, lo que básicamente duplicaba el recuento de hosts y servicios.

Aquí está ocurriendo algo inusual. Este pico inesperado levanta sospechas, ya que se desvía del comportamiento típico de los hosts legítimos. Aunque Internet suele tardar en parchear, no suele aumentar el número de hosts afectados tras el anuncio de una gran vulnerabilidad de día cero.

Cuando lo examinamos más de cerca, la causa de esta anomalía se hizo evidente: los honeypots.

En seguridad y redes, un honeypot suele ser un sistema o servicio diseñado estratégicamente para imitar objetivos reales. Su objetivo es atraer a los actores de amenazas para que interactúen con el servicio y se puedan supervisar sus actividades.

En Censys, hemos observado una clase específica de entidades engañosas similares a los honeypots que parecen diseñadas para atrapar a los escáneres de Internet, como ya comentamos en nuestro blog sobre Red Herrings y Honeypots. Estos servicios intentan emular muchos productos de software diferentes y legítimos a través de un servicio, dificultando la validación al inundar los conjuntos de datos con falsos positivos.

El número de nuevos hosts Ivanti Connect Secure fue nuestra primera pista de que algo iba mal. Casi de la noche a la mañana, el número total de hosts Connect Secure se duplicó, lo cual es un patrón anormal para un solo software.

La diferencia entre el recuento de hosts y el de servicios fue nuestra segunda pista de que probablemente se trataba de honeypots. Mientras que el recuento de hosts y servicios era similar al principio del periodo de tiempo, el recuento de servicios aumentó de forma desproporcionada con respecto al recuento de hosts durante los días siguientes, lo que indica que los hosts están creando varios servicios, cada uno de los cuales aparece como ejecutando Ivanti Connect Secure. En un despliegue medio de Connect Secure, sólo aparecerán uno o dos servicios ejecutando este software.

Otra pista condenatoria eran los nombres de dominio que aparecían en la sección de nombres comunes (CN) de los certificados TLS de cada servicio. Todos y cada uno de los nombres de dominio parecían fuera de lugar y, en algunos casos, demasiado buenos para ser verdad; es decir, si los dominios eran reales, serían objetivos de alto valor, como servidores de producción en dominios gubernamentales de primer nivel.

Utilizando una combinación de los dos últimos indicadores clave anteriores, hemos sido capaces de desarrollar una lógica simple que podría clasificar estos hosts como engañosos. La naturaleza exacta de este método se explicará más adelante en este post.

CensysPerspectiva de los servidores Ivanti Connect Secure reales

Excluyendo los servicios engañosos, la tendencia se ajusta más a lo que cabría esperar, mostrando un descenso gradual de hosts y servicios a medida que las organizaciones comienzan a desactivar instancias. El lunes 19 de febrero, 2024 Censys observó 24.590 puertas de enlace expuestas.

Mapa de puertas de enlace seguras Ivanti Connect expuestas el 19 de febrero de 2024 (no todas son necesariamente vulnerables)

¿Cuántos de ellos son potencialmente vulnerables?

El siguiente gráfico se centra en las instancias que muestran indicios de ejecutar una versión potencialmente vulnerable a cualquiera de las 5 vulnerabilidades recientemente reveladas en Ivanti Connect Secure (CVE-2023-46805, CVE-2024-21887, CVE-2024-21888, CVE-2024-21893 y CVE-2024-22024).

El lunes 19 de febrero, Censys observó 6.000 pasarelas Ivanti Connect Secure potencialmente vulnerables. Es alentador que esta cifra haya disminuido en un 56,5% desde las 13.970 instancias potencialmente vulnerables observadas el 31 de enero.

Las tendencias de la figura anterior también se corresponden con el calendario de anuncios de la CISA: obsérvese el acusado descenso tras la primera actualización de la Directiva Ejecutiva (DE) original publicada el 31 de enero. Hay una relativa meseta y un pequeño salto hasta el 9 de febrero, día en que la CISA publicó su segunda actualización y proporcionó orientaciones para "desconectarlo todo", tras lo cual el número de servicios vulnerables empezó a disminuir de nuevo.

A 19 de febrero, la concentración de estas pasarelas vulnerables es notablemente alta en Estados Unidos y Japón:

Muchos funcionan en una mezcla de las principales redes japonesas de telecomunicaciones e ISP. La mayor parte de la presencia estadounidense de estos hosts se concentra en Akamai, así como en Expedient, un proveedor de servicios en la nube. NTT Communications, KDDI y Arteria Networks son las principales empresas japonesas de telecomunicaciones y redes.

La versión vulnerable más común de Ivanti Connect Secure observada por Censys en el momento de escribir este artículo es la 22.3.17. Es preocupante que la versión 8.3.7 (End-of-Life, EOL) sea la segunda más popular. Esto sugiere que estos casos pueden ser hosts heredados que han sido descuidados o abandonados.

Indagar en los anfitriones engañosos

Ahora que conocemos los hosts reales que están expuestos y que ejecutan instancias de Ivanti Connect Secure potencialmente vulnerables, volvamos a los honeypots.

Inicialmente, estos hosts fueron etiquetados como hosts Ivanti Connect Secure en Censys, dado que sus cuerpos de respuesta HTTP contenían todos los signos reveladores de un servicio Ivanti Connect Secure legítimo. En otras palabras, sólo tras una inspección minuciosa descubrimos que se trataba de un engaño.

Más arriba, vemos que el 2 de febrero, el número de servicios Ivanti Connect Secure falsos aumentó a más de 17.000 hosts, y este es uno de los indicadores clave que nos da pistas sobre la magnitud de este engaño, una observación poco común dado que este aumento se produjo más o menos al mismo tiempo que los anuncios de vulnerabilidad.

Aislarse del ruido

Utilizamos tres indicadores principales para determinar lo que era legítimo y lo que no.

  1. El número de hosts únicos que ejecutan Ivanti Connect Secure se duplicó de la noche a la mañana. 
  2. Existe una diferencia cada vez mayor entre el número de hosts y el número de servicios de Ivanti Connect Secure (recuento de hosts sobre recuento de servicios).
  3. Elementos de nombre común sospechosos en el certificado TLS de cada servicio.

Puesto que ya hemos hablado del aumento del número de instalaciones y de la brecha cada vez mayor entre el número de hosts y servicios, vamos a profundizar en los nombres comunes sospechosos que encontramos en los certificados TLS.

dev.appliance.bright-manufacturing.mil
devo-hydro.state-medicine.ua
internal.thermal.first-finance.mil
piloto-vsphere.west-power.ua
private.sslvpn.city-oil.co.il
secret-kace.first-airforce.gov
staging.support.east-power.ca
piloto-sonicwall.south.oil.ca
A la izquierda, vemos algunos ejemplos de los nombres comunes encontrados en los certificados TLS de estos hosts.

A nosotros nos parecía que estos nombres se generaban a partir de una lista predefinida de palabras clave. Más concretamente, palabras clave elegidas estratégicamente para ser notables con el único propósito de atraer las miradas de un atacante.

Por ejemplo, descubrimos la presencia de múltiples dominios gubernamentales y federales de primer nivel, como ".gov" y ".mil", junto con tokens prefijados como "private", "dev" o "prod" (que denotan un sistema privado de desarrollo o producción). Todo ello podría considerarse un objetivo de gran valor.

Al realizar un análisis más exhaustivo de decenas de miles de estos nombres comunes "únicos", surgió un patrón en la disposición posicional de estos nombres de dominio aparentemente aleatorios. En primer lugar, analizamos cada nombre en subcadenas y anotamos su posición relativa, por ejemplo, con pilot-vsphere.west-power.ua:

 

Valor Posición de la subcadena
piloto 1
vsphere 2
oeste 3
potencia 4
ua TLD 

Hemos observado que cada subcadena tiene un conjunto predefinido de valores potenciales para su posición respectiva en la cadena. Puede observar que en la lista de ejemplos de nombres de certificados proporcionada anteriormente, el término "piloto" aparece exclusivamente en la posición más a la izquierda de la subcadena (Posición nº 1). Lo mismo ocurre con "piloto" en todos los nombres comunes que encontramos.

A continuación se muestran dos diagramas que muestran los patrones que descubrimos y sus respectivas posiciones de token ("P1" a "P4" y el "TLD"). Esto significa que en cada posición se utilizó un conjunto diferente de palabras para generar un nombre de dominio completo. Tanto si un punto como un guión unían los tokens, el número de posiciones seguía siendo el mismo.

A continuación se muestra una tabla en la que desglosamos estos conjuntos para generar los diez tokens más utilizados para cada posición correspondiente y el número de veces que observamos cada token en esa posición.

Posición 1 - #Ocurrencias Posición 2 - #Ocurrencias  Posición 3 - #Ocurrencias Posición 4 - #Ocurrencias TLD - #Ocurrencias
preprod 

37,804

servicio de asistencia 

13,923

brillante

46,555

aceite

40,150

ua

66699

prueba 

37,773

transportador

13,896

oeste

46,389

potencia

40,137

mil

66617

privado

37,621

docs

13,785

siguiente

46,048

aero

40,089

co.il

66610

corp

37,587

intercambiar

13,727

Ciudad

46,047

banco

39,992

ca

66505

beta

37,566

confluencia

13,701

estado

46,003

fabricación

39,941

us

66470

interno

37,548

cuentas

13,696

hoy

45,948

acero

39,924

gc.ca

66,432

desarrollo

37,349

soporte

13,692

novela

45,946

marina

39,898

com

66,220

investigación 

37,342

mfa

13,650

sur

45,934

eléctrico

39,839

org

65,941

devo

37,319

jira

13,622

este

45,905

seguridad

39,786

gov

65,522

piloto

37,216

envasado

13,620

principal

45,885

energía

39,747

N/A
MEDIA: 37,512.5 MEDIA: 13,731.2 PROMEDIO: 46066.0 MEDIA: 39,950.3 PROMEDIO: 66335.1

Como podemos ver, las palabras únicas utilizadas en sus respectivas posiciones tienen una distribución bastante uniforme, lo que indica un generador de números aleatorios decente, dando más credibilidad a que había un alto grado de automatización detrás de la creación y puesta en escena de estos hosts. A continuación se muestra un sencillo script en Python que imitará la funcionalidad básica de estos nombres de dominio (obviamente) generados por ordenador.

importar aleatorio
importar tiempo

p1_tareas = ["preprod", "test", "private" "etc..."]
p2_toks = ["helpdesk", "converyor", "docs", "etc..."]
p3_toks = ["brillante", "oeste", "siguiente", "etc..."]
p4_toks = ["oil", "power", "aero", "etc..."]
tld_toks = ["ua", "mil", "co.il", "etc..."]

random.seed(time.time())

p1_tok = p1_toks[int(random.random()) % len(p1_toks)]
p2_tok = p2_toks[int(random.random()) % len(p2_toks)]
p3_tok = p3_toks[int(random.random()) % len(p3_toks)]
p4_tok = p4_toks[int(random.random()) % len(p4_toks)]
tld_tok = tld_toks[int(random.random()) % len(tld_toks)]

print(f"{p1_tok}.{p2_tok}.{p3_tok}-{p4_tok}.{tld_tok}")

De uno surgen muchos

Censys detectó por primera vez un único host honeypot que ejecutaba Ivanti Connect Secure el 2 de febrero. Al cabo de un día, el recuento aumentó a 260 hosts y alcanzó rápidamente un máximo de 17.900 hosts el 7 de febrero. La capacidad de desplegar un número tan significativo de hosts en tan poco tiempo implica el uso de recursos considerables, lo que indica la participación de un actor bien financiado y no de un aficionado.

Censys empezó a etiquetar activamente a estos hospedadores de forma diferente el 15 de febrero, tras lo cual su número disminuyó ligeramente, pero siguen persistiendo.

Paciente Cero

El 2 de febrero de 2024, fue la primera vez que presenciamos un host con el falso Ivanti Connect Secure funcionando con las características descritas en la sección anterior (los nombres de dominio generados aleatoriamente).

 

IP 52.40.12.180
Puerto 2096
Sistema autónomo AMAZON-02 (AS16509)
País Estados Unidos
Versión Nulo (sin cuerpo hash)
Título HTML Ivanti Connect Secure
Nombre común del certificado  puesta en escena.siemens.today-oil.ca

Hay algunas cosas interesantes sobre este servicio:

  • Está alojado en un puerto aparentemente aleatorio que se aparta del comportamiento normal: la inmensa mayoría de las pasarelas Ivanti Connect Secure reales se concentran en el puerto 443, como muestra este gráfico:

  • El host está en AMAZON-02, una de las redes AWS más destacadas. Aquí es también donde se concentraban los honeypots la última vez que escribimos sobre ellos.
  • El nombre común del certificado levanta sospechas. A primera vista, parece un certificado legítimo, pero cuando se examina de cerca, el nombre común es una combinación inusual de palabras para la raíz y los subdominios.

Aislando los hosts que siguen este patrón de nomenclatura de certificados, a continuación se muestra cómo ha cambiado la distribución de hosts honeypot en las redes a lo largo del tiempo:

Dado que la mayoría de estos servicios están alojados en AWS, resulta difícil identificar a un propietario concreto. No obstante, un subconjunto más pequeño de hosts se encontraba en los sistemas autónomos "Ningxia West Cloud" y "BJ-GUANGHUAN", que actúan como proveedores de tránsito de AWS en China. Esto por sí solo apunta a la implicación de una organización con conexiones con China, ya que el titular de la cuenta debería tener una licencia comercial registrada oficialmente en China para crear hosts en esos sistemas autónomos específicos adyacentes a AWS.

Hay otro par de señales bastante evidentes de que son falsas:

1. Tendencias del recuento de huéspedes en ~10 países:

La siguiente figura muestra las tendencias en la geolocalización IP de estos hosts:

Fíjate en que parece haber unos 10 países con tendencias de recuento de hosts notablemente similares. Este patrón sugiere que estos hosts se desplegaron y controlaron sistemáticamente en cada país, probablemente mediante el uso de un script.

2. Título HTML uniforme, sin versiones

Todos ellos tienen exactamente el mismo título HTML: "Ivanti Connect Secure", y no se ha podido extraer ninguna versión de ninguno de ellos. Esas características compartidas refuerzan nuestra sospecha de un comportamiento "generado por script".

3. Rápido aumento del número de puertos por host

Con el tiempo, el número medio de puertos en cada host con Ivanti Connect Secure se cuadruplicó de 1 a 4, como se muestra en la siguiente figura. Es poco probable que el host legítimo medio tenga la puerta de enlace VPN ejecutándose en 4 puertos distintos simultáneamente, o que aumenten RIGHT a medida que se descubren vulnerabilidades importantes.

4. Rotación frecuente de certificados

Nos interesaba investigar si estos hosts actualizaban regularmente sus certificados o alteraban sus nombres. Aunque las motivaciones para la rotación frecuente de certificados varían, en el contexto de los hosts engañosos una hipótesis plausible es que lo hicieran para añadir un aspecto dinámico que hiciera más difícil distinguir entre sistemas reales y falsos, posiblemente evadiendo la detección durante más tiempo.

El siguiente gráfico ilustra la distribución del recuento de certificados únicos observados en un único puerto a lo largo de todo el periodo analizado (del 31 de enero al 19 de febrero).

Nombre común distintivo 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Número de servicios 16323 22465 23965 22935 19744 15552 10575 6547 3959 2007 797 347 152 42 25 8 6

Durante un periodo de 20 días, Censys registró una media de 4 certificados únicos presentados en un único puerto, con tres servicios específicos mostrando hasta 17 certificados diferentes. Esa tasa de rotación no es típica y sugiere que algo inusual está sucediendo aquí. De nuevo, a falta de pruebas más definitivas, se trata simplemente de una corazonada, pero coincide con nuestras otras observaciones.

Este patrón específico de hosts honeypot no es exclusivo de Ivanti Connect Secure. Hemos observado hosts similares que parecen estar ejecutando software relacionado con otros anuncios recientes de vulnerabilidades. Identificar a los responsables es difícil en este momento, pero cada vez hay más pruebas de que lo están haciendo deliberadamente. Estaremos atentos a la evolución de la situación. 🔎

¿Qué se puede hacer? Solución de las vulnerabilidades de Ivanti Connect Secure

Sobre el autor

El equipo de investigación Censys
Soluciones de gestión de la superficie de ataque
Más información