Una mirada al interior del formato de texto enriquecido de Microsoft y los exploits OLE


Ha habido un cambio dramático en las plataformas a las que atacan los atacantes en los últimos años. Hasta 2016, los navegadores solían ser el vector de ataque más común para explotar e infectar máquinas, pero ahora se prefieren las aplicaciones de Microsoft Office, según un informe publicado aquí durante marzo de 2019. El uso creciente de Microsoft Office como un objetivo de explotación popular plantea un desafío de seguridad interesante. Aparentemente, los documentos armados en archivos adjuntos de correo electrónico son un vector de infección superior.

Vinculación e incrustación de objetos (OLE), una tecnología basada en el Modelo de objetos componentes (COM), es una de las características de los documentos de Microsoft Office que permite que los objetos creados en otras aplicaciones de Windows se vinculen o incrusten en los documentos, creando así una estructura de documento compuesta y proporcionando una experiencia de usuario más rica . OLE ha sido abusado masivamente por los atacantes en los últimos años de varias maneras. Se han observado vulnerabilidades OLE en el pasado reciente, ya sea cargando objetos COM para orquestar y controlar la memoria del proceso, aprovechar las vulnerabilidades de análisis de los objetos COM, ocultar código malicioso o conectarse a recursos externos para descargar malware adicional.

El formato de texto enriquecido de Microsoft se usa mucho en los archivos adjuntos de correo electrónico en ataques de phishing. Ha ganado una popularidad masiva y su amplia adopción en los ataques de phishing se atribuye principalmente al hecho de que tiene la capacidad de contener una amplia variedad de exploits y se puede usar de manera eficiente como un mecanismo de entrega para atacar a las víctimas. Los archivos RTF de Microsoft pueden incorporar varias formas de tipos de objetos, ya sea para explotar las vulnerabilidades de análisis o para ayudar a una mayor explotación. los Unir e incluir objetos Se abusa en gran medida de la función de los archivos de formato de texto enriquecido para vincular el documento RTF con código malicioso externo o para incrustar otras vulnerabilidades de formato de archivo dentro de sí mismo y usarlo como contenedor de vulnerabilidades. Aparentemente, el formato de archivo RTF es muy versátil.

En las secciones a continuación, intentamos describir algunas de las estrategias de explotación e infección utilizadas en los archivos de formato de texto enriquecido de Microsoft en el pasado reciente y luego, hacia el final, introspectamos las conclusiones clave que pueden ayudar a automatizar el análisis de exploits RTF y establecer La dirección para el enfoque de análisis genérico.

Palabras de control de RTF

Los archivos de formato de texto enriquecido están formateados con palabras de control. Las palabras de control en los archivos RTF definen principalmente la forma en que el documento se presenta al usuario. Dado que estas palabras de control RTF tienen los parámetros y datos asociados, los errores de análisis para ellos pueden convertirse en un objetivo para la explotación. Se han encontrado vulnerabilidades en el pasado utilizando palabras de control para incorporar también recursos maliciosos. En consecuencia, se vuelve importante examinar una palabra de control de destino que consume datos y extrae la secuencia. Las especificaciones RTF describen varios cientos de palabras de control que consumen datos.

Los analizadores RTF también deben poder manejar los mecanismos de ofuscación de palabras de control comúnmente utilizados por los atacantes, para ayudar aún más al proceso de análisis. A continuación se muestra una de las vulnerabilidades de las instancias anteriores que utilizan parámetros de palabras de control para introducir cargas útiles ejecutables dentro de la palabra de control del almacén de datos.

Superposición de datos en archivos RTF

Los datos de superposición son los datos adicionales que se agregan al final de los documentos RTF y los autores de exploits los utilizan principalmente para incrustar archivos señuelo o recursos adicionales, ya sea en forma clara o encriptada, que generalmente se descifra cuando se ejecuta el código controlado por el atacante. . Los datos de superposición del volumen más allá de cierto tamaño deben considerarse sospechosos y deben extraerse y analizarse más a fondo. Sin embargo, el analizador RTF de Microsoft Word ignorará los datos superpuestos mientras procesa documentos RTF. A continuación se muestran algunos casos de exploits RTF con un mayor volumen de datos de superposición agregados al final del archivo, con CVE-2015-1641 incrustando tanto el documento señuelo como los códigos de shell de etapas múltiples con marcadores.

Vinculación e incrustación de objetos en archivos RTF

Los objetos vinculados o incrustados en los documentos RTF se representan como objetos RTF, precisamente a la palabra de control de destino RTF "objeto". Los datos para el objeto incrustado o vinculado se almacenan como el parámetro para la palabra de control de destino secundario RTF "objdata" en el código hexadecimal OLESaveToStream formato. La palabra de control del modificador "objclass" determina el tipo de objeto incrustado en los archivos RTF y ayuda a la aplicación cliente a representar el objeto. Sin embargo, los datos de objetos codificados en hexadecimal como argumento para la palabra de control "objdata" también pueden ofuscarse mucho, ya sea para hacer que la ingeniería inversa y el esfuerzo de análisis consuman más tiempo o para romper los analizadores RTF inmaduros. Aparentemente, OLE ha sido uno de los vectores de ataque dominantes en el pasado reciente, con muchas instancias de exploits basados ​​en OLE utilizados en ataques dirigidos, lo que implica esencialmente analizadores de documentos RTF robustos para la extracción de objetos, junto con una inspección más profunda de los datos del objeto es extremadamente crítico .

Vinculación de objetos: vincular RTF a recursos externos

Al usar la vinculación de objetos, es posible vincular los archivos RTF al objeto remoto que podría ser el enlace al recurso malicioso alojado en el servidor remoto. Esto hace que el archivo RTF resultante se comporte como un descargador y posteriormente ejecute el recurso descargado invocando los manejadores de recursos específicos de la aplicación registrados. Al inspeccionar las palabras de control RTF del modificador como "objeto", los objetos vinculados se indican mediante otra palabra de control anidada "objautlink", como se representa a continuación en el documento RTF.

Como se indica en la representación anterior, los datos del objeto como argumento de la palabra de control RTF "objdata" son OLE1.0NativeStream en el OLESaveToStream formato que es seguido por el NativeDataSize indicando el tamaño del documento compuesto OLE2.0 que está envuelto en NativeStream. Según las especificaciones del formato de texto enriquecido, si el objeto está vinculado a la aplicación contenedor, que en este caso es el documento RTF, la entrada del directorio de almacenamiento raíz del documento compuesto tendrá el CLSID de StdOleLink que indica el objeto vinculado. Además, cuando el objeto está en formato OLE2.0, los datos de origen vinculados se especifican en MonikerStream del OLESteam estructura. Como se resalta a continuación, al analizar los datos del objeto, el ole32.OleConvertOLESTREAMToIStorage La función es responsable de convertir los datos OLE1.0 NativeStream al formato de almacenamiento estructurado OLE2.0. Siguiendo el puntero a la secuencia OLE, lpolestream nos permitirá visualizar los datos nativos extraídos analizados. A continuación se muestra una instantánea de la memoria de cuando el proceso winword.exe analizó un documento RTF con un objeto vinculado.

Al iniciar el documento RTF con el enlace al objeto externo, aparecerá un cuadro de diálogo que le pedirá que actualice los datos del objeto vinculado, como se muestra a continuación.

Sin embargo, esta no es la estrategia de explotación ideal para atacar a las víctimas. Este error puede eliminarse insertando otra palabra de control modificador "objupdate", que internamente llama al objeto de enlace IOleObject :: Actualización método para actualizar la fuente del enlace.

Posteriormente se crea una instancia de urlmon.dll, que es el servidor registrado para la URL Moniker.

Una vez que se instancia el objeto COM, la conexión se inicia con el recurso externo y, en función del encabezado de tipo de contenido devuelto por el servidor en la respuesta, URL Moniker consulta la base de datos Mime en el registro e invoca controladores de aplicaciones registrados.

Microsoft describe los detalles sobre cómo se ejecuta URL Moniker y un algoritmo para determinar qué controladores apropiados invocar. aquí. Hemos tenido múltiples ataques RTF en el pasado, incluidos CVE-2017-0199, CVE-2017-8756 y otros que utilizan Monikers para descargar y ejecutar código remoto.

Sin embargo, los objetos COM utilizados en los exploits mencionados habían sido incluidos en la lista negra de Microsoft en las versiones más recientes, pero podrían usarse técnicas similares en el futuro que esencialmente requieren el análisis de flujos de almacenamiento estructurados OLE.

Incrustación de objetos: RTF que contiene controles OLE

Como se indicó anteriormente, los objetos incrustados se representan en los documentos del contenedor en el formato OLE2. Cuando el objeto se almacena en el formato OLE2, la aplicación contenedor (aquí archivos de formato de texto enriquecido) crea el almacenamiento de archivos compuestos OLE para cada uno de los objetos incrustados y los datos de objeto respectivos se almacenan en los objetos de flujo de archivos compuestos OLE. El diseño de los documentos del contenedor que almacenan objetos incrustados se representa a continuación y se describe en la documentación de Microsoft aquí.

Históricamente, se ha encontrado que los exploits RTF incorporan y cargan múltiples controles OLE para evitar las mitigaciones de exploits y aprovechar las vulnerabilidades de corrupción de memoria al cargar controles OLE vulnerables. Los controles OLE integrados en el documento RTF generalmente se indican mediante la palabra de control anidada "objocx" u "objemb" seguida de la "objclass" con el argumento como el nombre del control OLE para representar el objeto. A continuación se muestra uno de los ejemplos del exploit anterior utilizado en los ataques dirigidos, que explotó una vulnerabilidad en el objeto COM y cargó otro control OLE para ayudar al proceso de explotación que tenía incrustado el código malicioso en escena. Aparentemente, es crítico extraer los datos de este objeto, extraer el almacenamiento del archivo compuesto OLE2 y extraer cada uno de los objetos de flujo para una mayor inspección de códigos maliciosos ocultos.

Incrustación de objetos: RTF que contiene otros documentos

Los documentos RTF maliciosos pueden usar la funcionalidad OLE para incrustar otros formatos de archivo como archivos Flash y documentos de Word, ya sea para explotar las vulnerabilidades de los formatos de archivo respectivos o para ayudar aún más y establecer el escenario para el proceso de explotación exitoso. Se han observado múltiples exploits RTF en el pasado incrustando documentos OOXML utilizando la funcionalidad OLE para manipular la memoria de almacenamiento dinámico del proceso y evitar las mitigaciones de exploits de Windows. En los archivos RTF, los objetos incrustados generalmente se indican mediante la palabra de control anidada "objemb" con una cadena "ProgID" dependiente de la versión como argumento de la palabra de control anidada "objclass". Uno de esos exploits RTF utilizado en ataques dirigidos en el pasado reciente, es como se indica a continuación.

A continuación se muestra otra instancia en la que el archivo PDF se incrustó físicamente dentro del documento compuesto. Como se mencionó, el objeto incrustado se almacena físicamente junto con toda la información requerida para representarlo.

En el objeto incrustado, el identificador de la aplicación creadora se almacena en el campo CLSID de la entrada del directorio de archivos compuestos del objeto de almacenamiento CFB. Si echamos un vistazo a la instancia anterior, cuando los datos del objeto se extraen e inspeccionan manualmente, se observa el siguiente CLSID en el objeto de almacenamiento CFB, que corresponde al CLSID_Microsoft_Word_Document.

Cuando se analizan los objetos de flujo OLE2 y el OOXML incrustado se extrae y analiza después de desinflar el contenido, vemos la actividad sospechosa de carga de objetos ActiveX y el código malicioso incrustado en uno de los archivos binarios. Aparentemente, es importante extraer los archivos incrustados en RTF y realizar análisis adicionales.

Paquetes OLE en archivos RTF

Los documentos RTF también pueden incrustar otros tipos de archivos como scripts (VBSsript, JavaScript, etc.), archivos XML y ejecutables a través de paquetes OLE. Un paquete OLE en un archivo RTF se indica mediante la cadena ProgID "paquete"Como argumento de la palabra de control anidada" objclass ". El formato de empaquetador es el formato heredado que no tiene un servidor OLE asociado. Al observar el CLSID asociado en el registro, no hay un formato de datos específico asignado a los Paquetes.

Esto esencialmente implica que los paquetes OLE pueden almacenar múltiples tipos de archivos y, si un usuario hace clic en el objeto, conducirá a la ejecución del mismo y, eventualmente, a la infección de la máquina si son scripts maliciosos. Se sabe que los documentos RTF entregan malware al incorporar scripts a través de paquetes OLE y luego usar Monikers, como se describe en las secciones anteriores, para colocar archivos en el directorio deseado y luego ejecutarlos. A continuación se muestra una instancia de un documento RTF malicioso que explota CVE-2018-0802, incrustando un archivo ejecutable.

Dado que se han encontrado muchos documentos RTF que entregan malware a través de paquetes OLE, es fundamental buscar estos objetos incrustados y analizarlos en busca de tales cargas adicionales. Los archivos ejecutables / scripts integrados dentro de RTF pueden ser maliciosos. Buscar paquetes OLE y extraer archivos incrustados debería ser una tarea trivial.

Las estrategias de entrega de exploits anteriores pueden permitirnos dar un paso hacia la creación de marcos de análisis para documentos RTF. Principalmente, la inspección de los objetos vinculados o incrustados resulta ser el aspecto crítico de las tareas de análisis automatizado junto con la inspección de palabras de control RTF. Los siguientes son los puntos clave:

  • Utilizando el archivo RTF como contenedor, se pueden incrustar muchos otros exploits de formato de archivo en el interior utilizando la función de vinculación e incrustación de objetos, esencialmente armando los documentos RTF.
  • Extraer y analizar objetos incrustados o vinculados para código malicioso, carga útil o invocaciones de manejador de recursos se vuelve muy esencial.
  • Si el documento RTF tiene un mayor volumen de datos adjuntos, debe examinarse más a fondo.
  • Las palabras de control que no son OLE y los paquetes OLE también deben analizarse en busca de contenido malicioso.

Respuesta de McAfee

A medida que las vulnerabilidades de Microsoft Office continúan apareciendo, los métodos de inspección genéricos tendrán que mejorarse y mejorarse, lo que en consecuencia conducirá a mejores resultados de detección. Como recordatorio, el motor McAfee Anti-Malware utilizado en todos nuestros puntos finales y la mayoría de nuestros dispositivos tiene el potencial de desempaquetar documentos de Office, RTF y OLE, exponer los flujos de contenido y desempaquetar estos flujos si es necesario.





Enlace a la noticia original