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.
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