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.
El número de hosts únicos que ejecutan Ivanti Connect Secure se duplicó de la noche a la mañana. 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). 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 