Kaseya tiene una base de clientes de alrededor de 35.000 empresas y organizaciones. Estas consisten en aproximadamente 17.000 proveedores de servicios administrados, 18.000 clientes directos/VAR y una cantidad significativa de usuarios finales en las organizaciones a las que dan soporte. Sin duda, existe una gran superficie de ataque disponible para los actores de amenazas que podrían comprometer el software Kaseya VSA.
En el incidente de ransomware reciente ocurrido en julio de 2021, la industria se enteró de que entre 50 y 60 MSP y sus clientes administrados fueron cifrados por la pandilla de ransomware REvil a través del software de monitoreo y gestión remota Kaseya VSA.
Con solo entre 50 y 60 MSP afectados de un total potencial de 17.000 o 35.000, queda una gran pregunta pendiente… “¿Por qué no hubo más víctimas?”
Es decir, de manera más directa, “¿No debería haber habido más estragos?”
¿Pero Kaseya no cerró todo?
Inmediatamente después de reconocer el ataque, Kaseya tomó medidas para cerrar su plataforma VSA SaaS e instruyó a los clientes a apagar todos los servidores on-prem alrededor de las 1400 hora del Este. Este cierre podría usarse como explicación de por qué un número tan pequeño de clientes de VSA se vio afectado por una vulnerabilidad tan grave y generalizada. Sin embargo, hay dos cosas importantes que considerar aquí.
Primero, según Kaseya, la plataforma SaaS no era vulnerable a las vulnerabilidades explotadas. El cierre de la plataforma SaaS fue una medida reactiva tomada por exceso de precaución, pero no debería haber afectado directamente la cantidad de víctimas explotadas.
Segundo, los actores de amenazas sincronizaron este ataque para que ocurriera a las 1230 hora del Este del 2 de julio. Esto significa que la explotación inicial de los servidores VSA ocurrió antes del cierre. Observamos la ejecución de procedimientos sospechosos de Kaseya tan temprano como a las 0109 hora del Este del 2 de julio. Para cuando los clientes de VSA apagaron sus servidores, cualquier explotación ya se habría completado, y los ataques habrían ocurrido según lo planeado. Según algunos informes, hemos recibido reportes de clientes que encontraron remanentes de los procedimientos almacenados maliciosos al volver a conectar sus servidores VSA; sin embargo, cualquier orden de apagado después de las 1230 hora del Este no habría reducido la cantidad de MSP comprometidos.
La cadena de ataque
Huntress, junto con otros actores de la industria, ha observado que el incidente de ransomware usó una cadena de ataque que consistía en (1) una omisión de autenticación, (2) carga arbitraria de archivos y (3) ejecución remota de código.
Lo que nosotros y otros aún nos preguntamos es cómo los hackers obtuvieron la información necesaria para omitir la autenticación.
Siguiendo los pasos de explotación, la primera solicitud maliciosa fue al archivo público /dl.asp.
Este archivo contenía una falla lógica en el proceso de autenticación. Si no se proporcionaba una contraseña, no se proporcionaba, pero sí un identificador único de agente de Kaseya (un Agent GUID) válido, el usuario final iniciaba sesión exitosamente. En ese punto, el actor podía acceder a otras funcionalidades que requerían autenticación, todo sin una contraseña tradicional.
En el análisis del ataque, hemos visto y confirmado acceso malicioso simplemente proporcionando un GUID de agente único. No vimos indicadores de que los actores de amenazas hubieran forzado por fuerza bruta los GUID de agente; simplemente los conocían de antemano. No hubo intentos fallidos presentes en ningún registro.
Pero aún quedan preguntas pendientes: ¿Cómo obtuvieron los actores de amenazas un Agent GUID único?
Creemos que hay algunas opciones posibles.
Las opciones
1. Los actores de amenazas predijeron un Agent GUID o un nombre de visualización válido.
/dl.asp puede aceptar un GUID de agente o un nombre para mostrar. Sin embargo, el nombre para mostrar (por ejemplo, vsahost.root.kserver) no es el nombre real del equipo, varía de una organización a otra (sin ningún estándar en el uso de Kaseya VSA) y no parece ser predecible. En cuanto al GUID de agente, es una cadena de 15 caracteres generada aleatoriamente que tampoco se basa de ninguna forma en el nombre del equipo. Según los registros que observamos del incidente, no vimos ninguna señal de intentos de fuerza bruta contra el GUID de agente o el nombre para mostrar.
Fragmento de /dl.asp que muestra la aceptación tanto del GUID de agente como del nombre para mostrar
Según estos detalles, tenemos poca confianza en que los atacantes hayan podido predecir repetidamente un GUID de agente o un nombre para mostrar válidos en su primer intento.
2. Los actores de amenazas crearon un nuevo agente “no autorizado” y usaron ese nuevo GUID de agente.
El propósito original del archivo /dl.asp es crear y descargar un nuevo instalador de agente. El instalador de agente predeterminado está disponible para descargar sin autenticación. Después de una instalación exitosa, el usuario tendrá acceso a un GUID de agente nuevo y válido para el dispositivo recién registrado.
En los registros que tenemos, identificamos un agente sospechoso que se registró alrededor de la 1:00 a. m. hora del Este, el cual podría haber sido el agente malicioso. Sin embargo, no contamos con el contenido de las solicitudes ni con una captura de paquetes para verificar cómo se usó ese agente. Este misterioso agente también fue eliminado de la base de datos que recibimos, lo cual también resulta sospechoso. Parece poco probable que un MSP registrara un agente a la 1:00 a. m. hora del Este un viernes de fin de semana festivo.
Aunque el equipo del SOC de Huntress no pudo encontrar pruebas definitivas de que se haya registrado un agente “no autorizado”, creemos que esta opción es un escenario plausible. Sin embargo, vale la pena preguntarse “¿por qué el actor de amenazas no comprometió a más clientes de VSA?” si este método fue utilizado (de forma indebida).
3. Los actores de amenazas comprometieron un equipo que ejecutaba un agente de VSA y usaron ese GUID de agente.
Si el actor de amenazas ya tenía acceso a un equipo administrado por VSA, podría haber obtenido su GUID de agente del registro y luego haberlo usado para eludir la autenticación.
Aunque no hemos encontrado pruebas que respalden esta teoría, esta opción es ciertamente posible y podría explicar el radio de impacto relativamente pequeño que observamos durante el ataque. Requerir acceso inicial a un equipo comprometido que ejecute un agente de VSA es una dependencia interesante que haría de este un ataque mucho más sofisticado y organizado.
4. Se usaron otras vulnerabilidades conocidas/desconocidas para filtrar un GUID de agente.
Si bien hay siete vulnerabilidades que DIVD reveló y que Kaseya ya parchó públicamente, todavía existe la posibilidad de que haya más.
Dicho esto, incluso las vulnerabilidades identificadas públicamente podrían incluir capacidades que ofrecieran un GUID de Agent válido.
En particular, estas son las vulnerabilidades interesantes que podrían filtrar información:
- Filtración de credenciales y falla de lógica de negocio: CVE-2021-30116
- Vulnerabilidad de inyección SQL: CVE-2021-30117
Si bien no se observó una inyección SQL estricta en los registros, al igual que con las otras posibilidades, podría haberse hecho mucho antes de la explotación real y, potencialmente, desde direcciones IP distintas.
5. Los GUID de Agent o los nombres para mostrar ya eran información públicamente accesible.
No es ningún secreto que en los últimos años, Kaseya VSA ha sido víctima de incidentes de seguridad. Se han compartido volcados de datos en Tor Hidden Services y en los rincones de la "dark web", y aunque no hemos podido confirmarlo, existe la posibilidad de que los GUID de Agent ya estuvieran circulando.
Si este fuera el caso, tendría que existir una correspondencia entre el GUID de Agent y la organización respectiva. Si esa información estuviera incluida en una filtración, podría proporcionar toda la información necesaria para evadir la autenticación. Si esa correspondencia no estuviera presente y el actor de amenazas tuviera acceso solo a los GUID de Agent, correlacionarlos con la organización específica sería mucho más difícil.
¿Y ahora qué?
Reconocemos que esto es pura discusión y especulación. Considerando la gravedad de este ataque de ransomware generalizado, tenemos que preguntarnos "¿por qué esto se limitó a solo entre 50 y 60 MSP afectados, y por qué no más?"
Esperamos que al exponer estas posibles ideas sobre los orígenes de este ataque se muestre el nivel de exploración y comprensión que los proveedores y clientes deberían buscar, pero también que se plantee la idea de que esto podría haber sido mucho peor.
¿Había otras vulnerabilidades que desconocíamos? ¿Faltaba inteligencia en Screenshot.jpg que pudiera revelar más del panorama general? ¿Se habían filtrado previamente múltiples GUID de agente o ya eran información pública? ¿Aprendieron los actores de amenazas de incidentes anteriores (como Colonial Pipeline) que un impacto mucho mayor podría provocar la intervención del gobierno? Simplemente no lo sabemos.
Si alguna organización tiene una copia completa de este Screenshot.jpg malicioso, por favor comparte tus hallazgos y el archivo con nosotros a support[at]huntress.com.
Lo que sí sabemos, sin embargo, es que el radio de impacto de este incidente fue significativamente menor de lo que podría haber sido. Cuando los titulares y los artículos de noticias afirman que este es el "mayor ataque de ransomware hasta ahora", la industria tiene que enfocarse en ese componente clave: "hasta ahora."
Podemos estar agradecidos de que este ataque haya sido relativamente limitado, pero no podemos perder de vista ni dejar de profundizar para entender por qué, de modo que podamos estar mejor preparados para la próxima amenaza, sea cual sea. Lo que acecha a la vuelta de la esquina podría ser peor…
* Un agradecimiento especial a los compañeros investigadores de seguridad de Huntress Caleb Stewart y Dave Kleinatland por sus aportes y ayuda en la preparación de este artículo.
