El grupo de ransomware CL0P aprovecha la vulnerabilidad de día cero SQLi de MOVEit (CVE-2023-34362)
Autores: Ori David, Sam Tinklenberg, Maxim Zavodchik y Ophir Harpaz
Resumen ejecutivo
El 31 de mayo de 2023, Progress Software comenzó a advertir a los clientes sobre una vulnerabilidad anteriormente desconocida en el software MOVEit Transfer y MOVEit Cloud. Los atacantes han explotado activamente la vulnerabilidad de inyección SQL (SQLi), denominada CVE-2023-34362.
Según un informe de Mandiant, se han detectado intentos de explotación de esta vulnerabilidad desde el 27 de mayo de 2023. Ese mismo día, los investigadores de Akamai detectaron intentos de explotación contra uno de los clientes financieros de Akamai, ataque que fue bloqueado por el motor de seguridad adaptable de Akamai.
La campaña de ataque se atribuyó a un grupo de ransomware denominado CL0P. El grupo, cuya sede parece estar en Rusia o Europa Oriental, tiene motivación financiera y se sabe que extorsiona a sus víctimas a través de la exfiltración de datos.
Los atacantes han aprovechado la vulnerabilidad SQLi para implementar un shell web ASP.NET personalizado (LEMURLOOT) con el fin de lograr persistencia en las redes de las víctimas y facilitar un ataque posterior.
En el momento de redacción de este documento, no están a disposición del público todos los datos del ataque. Sin embargo, el análisis realizado por el grupo de inteligencia sobre seguridad de Akamai y la colaboración con el equipo de seguridad de Progress nos permiten confirmar que el motor de seguridad adaptable ha protegido a nuestros clientes contra los intentos de ataques.
Cronología
Fig. 1: Cronología de eventos de la campaña de explotación de MOVEit
El 31 de mayo de 2023, Progress Software publicó un aviso y comenzó a avisar a sus clientes sobre una vulnerabilidad de día cero en MOVEit Transfer y MOVEit Cloud, que los atacantes estaban explotando activamente para poner en peligro los servidores web (Figura 1).
Esta alerta se activó tras la identificación de una campaña de explotación masiva que estaba aprovechando esta vulnerabilidad para extraer archivos confidenciales almacenados en servidores vulnerables. Según Mandiant, los intentos de explotación de la vulnerabilidad se detectaron desde el 27 de mayo de 2023. Huntress llevó a cabo un análisis técnico de la vulnerabilidad para demostrar que esta podría provocar una ejecución remota completa de código en el servidor.
Microsoft atribuyó oficialmente este ataque al grupo Lace Tempest el 2 de junio de 2023, hecho que fue finalmente confirmado el 5 de junio, cuando CL0P publicó un comunicado sobre esta campaña en su blog (Figura 2).
Fig. 2: El grupo de ransomware CL0P anuncia su participación en la campaña MOVEit
Alcance de los ataques
En el momento en que el ataque ya se conocía y se estaba investigando, Shodan identificó unos 2500 servidores web que ejecutaban MOVEit (Figura 3).
Fig. 3: Una consulta de Shodan detectó que más de 2500 servidores web ejecutaban una versión vulnerable de MOVEit
Progress Software indicó que todos los servidores que ejecutaban MOVEit eran vulnerables y que no existía ningún parche en el momento del ataque masivo. Por lo tanto, no nos equivocamos si asumimos que el número de víctimas es considerable. Ya se ha confirmado que varias organizaciones han sufrido filtraciones y es probable que se conozcan muchas más en los próximos días.
Cadena de ataques
Se ha publicado mucha información sobre esta vulnerabilidad. Sin embargo, aún no se han hecho públicos todos los datos sobre el ataque. Según la información pública disponible, el análisis realizado por el grupo de inteligencia sobre seguridad de Akamai y los datos que aparecen en nuestros registros, tenemos una idea clara de cómo se utiliza moveitisapi.dll para llevar a cabo ataques SQLi.
Además, nuestro equipo se reunió con el equipo de seguridad de Progress para compartir información, nuestro análisis y otros detalles relacionados con los indicadores de compromiso (IoC, del inglés Indicators of Compromise). Teniendo en cuenta los resultados de esta reunión, podemos confirmar que el motor de seguridad adaptable de Akamai ha protegido y sigue protegiendo a nuestros clientes mutuos contra este ataque.
Podremos publicar más datos sobre nuestro análisis y la cadena de ataques cuando haya transcurrido el tiempo suficiente para permitir la aplicación de parches.
Ocultación de la operación
El grupo CL0P ha realizado varios intentos por pasar desapercibido y dificultar el análisis.
En primer lugar, el nombre del shell web cargado era "human2.aspx", muy similar al archivo MOVEit original que implementa la interfaz web, denominado "human.aspx".
En segundo lugar, para acceder al shell web era necesario enviar una contraseña mediante el encabezado "X-siLock-Comment". Si este faltaba o la contraseña era incorrecta, el shell web devolvía la respuesta 404 No encontrado. En muchas ocasiones, el método más sencillo de encontrar un shell web es enviar una simple solicitud GET. Si la página no existe, se devuelve un error 404. El hecho de que el shell web devuelva un error de este tipo solo evita el método más sencillo de detección. Con unos pocos pasos adicionales puede comparar la respuesta 404 del shell web con la respuesta 404 normal del servidor y ver la diferencia entre las dos.
En tercer lugar, los encabezados utilizados para controlar el shell web y enviar ataques utilizaban nombres muy similares a los nombres de encabezado originales de MOVEit. Por ejemplo, se utilizaba "X-siLock-Comment" para transmitir la contraseña del shell web. También se filtró otro tipo de información de la base de datos de MOVEit mediante encabezados con nombres similares: "X-siLock-Step2" y "X-siLock-Step3".
Detección del ataque
Los intentos de ataques se pueden identificar de varias formas.
Indicadores de riesgo (IoC) conocidos
Progress Software y la comunidad de seguridad han publicado numerosos indicadores de riesgo basados en host y en red , como direcciones IP, hash de archivos y reglas de YARA.
Los administradores de red pueden supervisar el tráfico de red y los registros de IIS, así como analizar los activos de la red para encontrar IoC conocidos y, de esta forma, poder identificar los equipos infectados.
Los clientes del motor de seguridad adaptable pueden consultar sus registros de firewall de aplicaciones web (WAF, del inglés Web Application Firewall) para buscar indicios de ataque. Si sus hosts de MOVEit han sido objeto de los ataques, deberían aparecer activadores del grupo de ataque SQLi orientados a "/moveitisapi/moveitisapi.dll".
Búsqueda de amenazas
Se deben investigar y analizar los servidores que ejecutan el software vulnerable para detectar comportamientos anómalos, incluso aunque no se hayan detectado IoC conocidos en ellos. Por ejemplo, tras inspeccionar la carga útil que los atacantes han utilizado, observamos que se colocó un shell web aspx en el directorio raíz del servidor en <Letra de unidad>: \MOVEitTransfer\wwwroot\. El shell web implementado en la campaña de ataque original se denominaba human2.aspx, pero este indicador podría cambiar fácilmente.
En lugar de depender únicamente de IoC estáticos, recomendamos usar métodos de búsqueda de amenazas basados en anomalías en los servidores vulnerables. En este caso concreto, un enfoque podría ser comprobar el directorio raíz del servidor MOVEit para buscar cualquier archivo aspx que se haya creado recientemente. Los archivos aspx son de naturaleza relativamente estática y no suelen modificarse ni crearse, por lo que un nuevo archivo de este tipo podría resultar sospechoso y, por tanto, debería investigarse. Se publicaron rutas de archivos sospechosas adicionales en el aviso inicial de Progress, al igual que en un reciente aviso #StopRansomware de la CISA.
Los clientes de Guardicore Segmentation de Akamai pueden utilizar la consulta de Insight que se muestra en la Figura 4 para buscar dichos archivos.
Fig. 4: Consulta de Insight para buscar cualquier archivo aspx que se haya creado recientemente
Tenga en cuenta que la letra de la unidad (C:\) y la ruta de instalación pueden variar; esta consulta solo se aplicará a la ruta de instalación predeterminada.
Akamai Hunt, el servicio gestionado de búsqueda de amenazas de Akamai, ha realizado análisis exhaustivos de los entornos de los clientes para detectar los posibles activos vulnerables, intentos de ataques e IoC asociados a la campaña de ataque. En los casos en que se encontraron componentes de MOVEit, los investigadores de Hunt informaron a los equipos pertinentes y ayudaron a mitigar la amenaza de forma inmediata (Figura 5).
Fig. 5: Alerta de Hunt sobre un intento de ataque de MOVEit detectado en un entorno de cliente
Mitigación
Lamentablemente, las vulnerabilidades de software son inevitables, pero las organizaciones pueden tomar muchas medidas para protegerse contra este tipo de filtraciones.
Identificación de los servidores web
Para poder mitigar el ataque, los defensores tienen que identificar antes de nada qué aplicaciones web confidenciales están ejecutando. En el caso de MOVEit, Progress informó a todos los clientes vulnerables sobre la vulnerabilidad. Sin embargo, sigue siendo fundamental conocer la superficie de ataque externa e identificar todas las aplicaciones confidenciales que están expuestas a Internet. Una vez identificadas estas aplicaciones, los siguientes pasos para la mitigación pueden reducir el riesgo de que las aplicaciones queden expuestas.
Limitación del acceso a Internet
La reducción de la superficie de ataque debe ser la máxima prioridad. Si no hay una razón justificada para el acceso a Internet no autorizado a una aplicación, esta se debe proteger con controles de acceso basados en el usuario, lo que se puede conseguir a través del acceso de red Zero Trust (ZTNA) o de productos de VPN tradicionales.
Si se necesita acceso a Internet no autorizado para algunos casos de uso, le recomendamos que ejecute un servidor de aplicaciones externo independiente, que limite los datos almacenados en él o a los que se pueda acceder desde él y que lo segmente en la red interna en la medida de lo posible. De esta forma, incluso si se produjera una filtración en el servidor de aplicaciones, el radio de efecto sería limitado.
Bloqueo de la explotación con un WAF
Las aplicaciones con interfaces web deben estar protegidas por un WAF, ya que este puede bloquear solicitudes anómalas y sospechosas y, de esta forma, bloquear la explotación de vulnerabilidades de día cero anteriormente desconocidas.
Según nuestros conocimientos actuales de la cadena de ataques, el motor de seguridad adaptable de Akamai proporciona protección contra este ataque con el grupo de ataque SQLi. En concreto, hemos identificado instancias en las que el motor de seguridad adaptable ha impedido que los atacantes aprovechen la vulnerabilidad SQLi. Las solicitudes bloqueadas se originaron en las direcciones IP enumeradas en los IoC conocidos.
Prevención del movimiento lateral con la segmentación
Los servidores web se pueden convertir en muchas ocasiones en el punto de entrada de los atacantes de la red. Teniendo esto en cuenta, esos servidores deben tratarse en consecuencia y mantenerse en un segmento independiente, lo que limita la capacidad del atacante de realizar movimientos laterales dentro de la red.
Por ejemplo, se puede crear una regla para bloquear todas las conexiones salientes de los servidores web a través de puertos de gestión (Figura 6).
Fig.6: Regla de ejemplo en Guardicore Segmentation de Akamai para bloquear los intentos de movimiento lateral
De esta forma, si un atacante penetrara en el servidor, sería imposible realizar movimientos laterales en estos puertos. Se deben crear reglas adicionales para las aplicaciones confidenciales y otros puertos de gestión con el fin de limitar la superficie de ataque de estos servidores en la medida de lo posible. Tenga en cuenta que dichas reglas también podrían interrumpir las operaciones normales de la red, por lo que debe tener precaución al crearlas y añadir la exclusión al tráfico existente necesario para las operaciones diarias.
¿Hasta la próxima?
MOVEit es otro caso de explotación de vulnerabilidad de día cero de un servicio de transferencia de archivos gestionada (MFT, del inglés Managed File Transfer). Hasta ahora, el grupo de ransomware CL0P se ha hecho conocido por este tipo de actividad; anteriormente había aprovechado vulnerabilidades en las aplicaciones GoAnywhere, SolarWinds Serv-U y Accellion con el objetivo de robar datos y extorsionar a sus víctimas, además de haber aprovechado más vulnerabilidades en otras aplicaciones web.
De hecho, si tiene cualquiera de las principales soluciones de MFT instaladas en la red, es prácticamente seguro que, mientras está leyendo esta frase, un hacker muy cualificado y motivado en algún lugar del mundo estará analizando estas aplicaciones e intentando descubrir sus brechas de seguridad. Parece que solo es cuestión de tiempo hasta que el grupo CL0P lance una nueva campaña de ataques. Además, es muy probable que más grupos sigan su ejemplo.
