Microsoft Office Security: objetos incrustados

Inicialmente, la arquitectura de Microsoft Office fue construida sobre la base del concepto de documentos compuestos, también son documentos OLE , promovidos activamente por Microsoft en los albores de Windows de 32 bits. En aquellos días, la idea de combinar "sin problemas" datos de varios formatos en un documento parecía atractiva y fascinante, y antes de identificar los primeros problemas, logró crecer firmemente en muchos productos a gran escala.

La "mala noticia" fue que la forma universal de agregar datos (y el código para procesar estos datos) en los documentos se ha convertido en una forma universal de introducir vulnerabilidades en el producto, que aún hoy presenta sorpresas agradables para los creadores de investigadores de seguridad de malware .

Posteriormente, el paquete de la aplicación recibió un conjunto bastante rico de herramientas para agregar imágenes, gráficos y tablas, elementos de control que la aplicación crea y procesa y que forman parte de ella en los documentos. Desde el punto de vista de la seguridad, estos elementos tienen un poco menos de interés que los elementos que (principalmente) se analizarán en el artículo: elementos que usan el código de aplicaciones externas que se agregan a los documentos que usan OLE.

Una representación de "disco" de un documento compuesto es un archivo CFBF . Este artículo discutirá la incrustación de objetos en documentos de Microsoft Office (o más bien, solo el aspecto de seguridad) en el contexto de datos y código cargados en la memoria en tiempo de ejecución.

Los objetos incrustados formalmente en documentos de Microsoft Office se pueden dividir en los siguientes grupos:

• Controles ActiveX (controles ActiveX)
• Objetos incrustados OLE
• Archivos incrustados ( paquetes )
• Elementos en línea no OLE

Controles ActiveX

Los controles ActiveX pueden considerarse como elementos de una ventana de programa (por ejemplo, botones, interruptores, listas, campos de entrada y otros formularios) diseñados para producir ciertos eventos o responder a eventos. Érase una vez, parecía una buena idea crear tales elementos de control universales, con la posibilidad de uso en cualquier aplicación, y ponerlos para este propósito en componentes COM .

Las páginas web integradas de ActiveX representaban una conocida violación de seguridad de Internet Explorer, las medidas de seguridad aumentaron con el tiempo. Los navegadores de otros fabricantes abandonaron casi de inmediato la compatibilidad con ActiveX. El nuevo navegador Microsoft Edge finalmente se separó de esta reliquia del pasado. Sin embargo, todavía es posible incrustar en documentos de Office.

ActiveX en documentos está diseñado para usarse junto con Visual Basic para Aplicaciones . Sin embargo, no se requiere VBA para descargarlos y activarlos, y no se requiere permiso del usuario para descargar elementos de la lista blanca .

Las vulnerabilidades en este último son especialmente peligrosas: la configuración predeterminada que se establece al instalar la aplicación no implica ninguna protección contra la carga de estos elementos, ni una advertencia para el usuario. El administrador debe ajustar la configuración al prohibir la carga de cualquier control ActiveX (sin embargo, tenga en cuenta que ActiveX no se carga en el modo Navegación segura).

Ejemplo: CVE-2012-0158

Una de las vulnerabilidades más peligrosas en los documentos de Office en 2012 fue CVE-2012-0158 . El código de carga para el elemento Microsoft ListView Control 6.0 de la biblioteca MSCOMCTL.OCX contenía la posibilidad de desbordamiento del búfer, lo que permitió reemplazar la dirección de retorno y ejecutar código arbitrario. Como el elemento estaba en la "lista blanca" de ActiveX, la carga comenzó inmediatamente cuando se abrió el documento. La vulnerabilidad está arreglada actualmente, el control ListView todavía se considera "seguro".

Agregar ActiveX a un documento

Para agregar un elemento de control a un documento de Microsoft Office (por simplicidad, tome Word), use la interfaz de usuario para abrir la pestaña "Desarrollador" (su visibilidad está configurada en el menú "Opciones de Word") y seleccione Controles -> Herramientas de versiones anteriores -> Controles ActiveX. El menú mostrará un conjunto de iconos correspondientes a elementos de Microsoft Forms, así como la capacidad de seleccionar ActiveX de la lista compuesta de elementos disponibles en el sistema que se seleccionan de acuerdo con una serie de criterios.



La lista que se muestra no corresponde al conjunto de elementos que realmente se pueden cargar en el documento, por lo tanto, no se puede guiar al buscar elementos vulnerables. La verificación sofisticada de varios niveles de ActiveX descargado tiene varias etapas, difiere para las versiones de Office y varía de una actualización a otra, por lo que la forma más segura de verificar la descarga es "componer" manualmente el archivo del documento con el elemento de interés e intentar abrirlo en Office. Los posibles formatos de documentos se describen a continuación.

Presentación del programa

Cada elemento ActiveX es esencialmente un objeto de una de las clases COM que cumplen ciertos requisitos. Un elemento se carga utilizando el subsistema COM, y el código ejecutable está contenido en uno de los módulos, que generalmente son "externos" a la aplicación contenedor. Al igual que cualquier objeto COM, un elemento ActiveX puede implementarse como una DLL o como un archivo ejecutable EXE. En el primer caso, la biblioteca se cargará en el espacio de direcciones del contenedor, en el segundo: el elemento se procesará en un proceso separado, con la transferencia de datos entre el contenedor y el objeto a través de la clasificación COM.

Al igual que cualquier objeto COM, ActiveX tiene interfaces , propiedades y métodos .

Las interfaces son principalmente un conjunto de interfaces estándar que la clase ActiveX debe tener para una carga completa e interacción con el contenedor, en particular, IOleControl e IOleObject.

La ausencia de las interfaces necesarias puede reducir la funcionalidad del elemento o interrumpir su carga en algún momento.

Ejemplo: CVE-2015-2424
La vulnerabilidad CVE-2015-2424 se asoció con el elemento de clase TaskSymbol de la biblioteca mmcndmgr.dll. El elemento no estaba destinado para su uso en documentos y no exportó la interfaz IDispatch. En el proceso de cargar un elemento, el procedimiento que solicitó esta interfaz recibió un error y destruyó la estructura interna del elemento, lo que condujo a una vulnerabilidad del tipo libre de uso posterior. Por el momento, el elemento no se puede descargar (a pesar de esto, todavía se puede encontrar en la lista para agregarlo al menú "Desarrollador"). La vulnerabilidad en sí no se resuelve.

Además de los estándares, cada clase ActiveX exporta la interfaz "principal", que representa su propia funcionalidad única. Por ejemplo, para la clase Forms.CommandButton.1, esto es ICommandButton.

Puede ver las interfaces ActiveX con la herramienta OleView incluida en el paquete de Microsoft Visual Studio.



La interfaz de un elemento define sus métodos y propiedades . Las propiedades representan algunos datos que determinan la apariencia y el funcionamiento de un elemento. El desarrollador de un elemento ActiveX asigna un nombre específico a cada propiedad, digamos BackColor o GridLineWidth, y un tipo, por ejemplo, una cadena, un entero o una precisión doble real. Para imágenes e iconos de mapa de bits, hay un tipo de propiedad, como una imagen. El programa cliente puede establecer propiedades individuales del control estableciendo sus índices y valores enteros.

Desde el punto de vista de una implementación de bajo nivel, la división en métodos y propiedades es formal, ya que las "propiedades" están representadas por un conjunto de métodos get / set. Sin embargo, hay una diferencia significativa: los métodos de un elemento (su interfaz principal) solo se pueden llamar mediante programación, en el caso de documentos de Office, solo desde un programa VBA en ejecución. Desde el punto de vista de la seguridad, esto no es de gran interés, ya que la ejecución de VBA ya es un compromiso del sistema operativo. Las propiedades se guardan en el documento y cuando se abre, se procesarán y cargarán en las estructuras de la memoria, incluso si se prohíbe la ejecución de VBA .

Desde el punto de vista del software, por parte del elemento, para preservar sus propiedades y estado en el documento, el contenedor proporciona las interfaces IStream , IStorage e IPropertyBag . Su implementación y presentación de datos en un archivo de disco ya no es una preocupación del elemento ActiveX, y depende completamente del contenedor y el formato del documento. Cabe señalar que el conjunto y el formato de los datos almacenados pueden corresponder a un conjunto de propiedades exportado "públicamente", o puede ser completamente diferente. Considere ejemplos de implementación relacionados con Microsoft Office.

Archivo compuesto (CFBF)

El formato de documento de Office obsoleto , donde el almacenamiento de nivel inferior de ObjectPool y subdirectorios separados dentro de él se asignaron para almacenar datos ActiveX. La secuencia "\ 001CompObj" contiene el identificador de clase, que finalmente determina la clase del objeto cargado. Reemplazar el identificador directamente en hexadecimal dará como resultado un intento de cargar un objeto de una clase completamente diferente .

Office Open XML

Formato de documento XML moderno. El archivo es un archivo zip. Los datos de control de ActiveX se almacenan en el subdirectorio ActiveX en archivos con nombres simples como activeX1.xml.



Archivo de ejemplo:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<ax:ocx ax: classid="{D7053240-CE69-11CD-A777-00DD01143C57} " ax: persistence="persistPropertyBag" xmlns:ax="http://schemas.microsoft.com/office/2006/activeX" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships">
<ax:ocxPr ax:name="Caption" ax:value="CommandButton1"/>
<ax:ocxPr ax:name="Size" ax:value="2540;847"/>
<ax:ocxPr ax:name="FontName" ax:value="Calibri"/>
<ax:ocxPr ax:name="FontHeight" ax:value="225"/>
<ax:ocxPr ax:name="FontCharSet" ax:value="204"/>
<ax:ocxPr ax:name="FontPitchAndFamily" ax:value="2"/>
<ax:ocxPr ax:name="ParagraphAlign" ax:value="3"/>
</ax:ocx>

En estos archivos, los identificadores de clase se indican en forma de texto. Reemplazar el identificador también provocará un intento de cargar un elemento de otra clase.

A continuación, el archivo contiene una indicación del tipo de almacenamiento de datos del objeto: persistPropertyBag, persistStorage o persistStream. Si un elemento admite propiedades persistPropertyBag , sus datos se pueden almacenar en el mismo archivo de texto , consulte el ejemplo anterior. Si necesita almacenamiento o una secuencia binaria , los datos se guardarán en un archivo con un nombre del tipo activeX1.bin, que es un archivo CFBF .

RTF

En un documento rtf, el elemento ActiveX está definido por las etiquetas \ object \ objocx . La etiqueta \ objdata contiene el almacén de propiedades del elemento como una representación hexadecimal del archivo CFBF.

{\object\objocx\f37\objsetsize\objw1440\objh480{\*\objclass Forms.CommandButton.1}
{\*\objdata 010500000200000016000000
466f726d732e436f6d6d616e64427574746f6e2e31000000000000000000000e0000
d0cf11e 0a1b11ae1000000000000000000000000000000003e000300feff090006

Descargar desde archivo

El proceso de cargar ActiveX desde un documento en su conjunto es bastante simple. La aplicación contenedor crea un objeto limpio de la clase especificada, le solicita la interfaz de almacenamiento especificada y proporciona un puntero al almacenamiento, flujo o "paquete de propiedades".

Filtrar elementos que se pueden cargar tiene muchos pasos. En primer lugar, se eliminan las clases especificadas en la lista negra conocida como Office COM Kill Bit (sugerencia de registro * OFFICE_KEY * \ Common \ COM Compatibility). Por ejemplo, los indicadores anti-descarga tienen clases como Microsoft Scriptlet Component y Microsoft Web Browser.

Las clases restantes pasarán por la carga inicial. Esto significa que la DLL se cargará en la aplicación contenedor o se iniciará el proceso del servidor COM implementado en el archivo EXE. Solo después de eso, se realizarán el resto de las verificaciones, incluida la primaria, y si el objeto es, de hecho, un representante de ActiveX.

Ejemplo: CVE-2015-6128
En 2015, el investigador descubrió que la precarga de módulos COM se puede utilizar para omitir ASLR y ejecutar código arbitrario al cargar bibliotecas dinámicas falsas. El CVE-2015-6128 lanzado posteriormente no es una palabra sobre Microsoft Office.

Si el identificador realmente define ActiveX, pasará por varias verificaciones más en varias listas en blanco y negro.


Puede ver que un lugar significativo en la lista está ocupado por los componentes del grupo Formularios de Microsoft . Este es un conjunto de controles que vienen con Office, y puede verlos en el panel de controles ActiveX. Inicialmente, todos estaban registrados como "seguros", pero con el tiempo se hizo evidente que esto no era así para elementos individuales. Por ejemplo, el elemento Frame carga cualquier otro ActiveX sin verificar ninguna lista (en las últimas versiones esto es "fijo", pero la propia lista negra de Frame es diferente de la Oficina general). Por esta razón, algunos elementos de Microsoft Forms solo pueden cargarse en un documento con el permiso del usuario. Microsoft Forms Frame también requiere el consentimiento del usuario (en la configuración predeterminada), pero le permite descargar algunos elementos de la lista Kill Bit que no se pudieron cargar en otras condiciones.

Por lo tanto, si un atacante logra convencer al usuario de que permita que ActiveX se cargue, Frame lo ayudará a expandir significativamente el arsenal debido a elementos como, por ejemplo, el navegador web.

El formato de almacenamiento de propiedades de Microsoft Forms está parcialmente documentado por la especificación [MS-OFORMS] .

Durante el análisis de ActiveX, resultó que el conjunto de clases para doc, docx y rtf es diferente, también hay diferentes listas de ActiveX disponibles para una aplicación que se ejecuta de la manera habitual y en modo de automatización .

Muchas aplicaciones populares complementan estas listas con su propio ActiveX. Si se descubre una vulnerabilidad, se reflejará en el boletín como relacionada con la aplicación de la que forma parte. Sin embargo, la única forma de aprovechar la vulnerabilidad pueden ser los documentos de Office.

Ejemplo: Flash ActiveX
Los escritores de virus apreciaron especialmente a Flash ActiveX por sus vulnerabilidades consistentemente detectables y un lugar permanente en las listas blancas de IE y Office. Las primeras vulnerabilidades conocidas en este componente aparecieron en 2008, una de las últimas CVE-2018-4878 se cerró en febrero de este año. Con la creciente popularidad de IE, los documentos de Office se han convertido en la principal forma de distribuir exploits para Flash.

Elementos de datos OLE integrados

Los elementos OLE implementados están diseñados para implementar el concepto de "documento en documento" con la capacidad de editar datos in situ de varios formatos procesados ​​por otras aplicaciones. Al igual que ActiveX, los documentos OLE se implementan sobre la base de COM.

Puede agregar un elemento OLE a un documento de Word de la siguiente manera: abra la pestaña "Insertar" y seleccione Texto -> Objeto. El programa muestra una lista de tipos de documentos para los que los controladores OLE están registrados. Como es el caso con ActiveX, esta lista no coincide con el conjunto de clases que realmente se pueden cargar como documentos OLE.

Presentación del programa

Como en el caso de ActiveX, la implementación de cualquier documento OLE está representada por la clase COM correspondiente, realizada en forma de DLL o EXE. El componente exporta las interfaces de servicio necesarias y el estado se guarda en el documento contenedor a través de las interfaces IPersist *.

En un documento CFBF, los datos del objeto OLE se almacenan en el almacenamiento de segundo nivel de ObjectPool. Un conjunto de subprocesos es generalmente similar a los controles ActiveX correspondientes.



En los documentos XML de Open Office, los datos del objeto OLE se almacenan en el subdirectorio de incrustaciones, en un archivo de almacenamiento CFBF con un nombre de tipo oleObject1.bin.



En los documentos RTF, la información del objeto se almacena bajo la etiqueta \ object \ objemb \ . La sección también contiene almacenamiento codificado como una representación hexadecimal del archivo CFBF.

{\object\objemb\objw8307\objh553{\*\objclass WordPad.Document.1}
{\*\objdata 010500000200000013000000576f72645061642e446f63756d656e742e31000000000000000000000a0000
d0cf11e 0a1b11ae100000000


El formato RTF se distingue por el hecho de que admite la etiqueta \ objupdate , que provoca la activación automática del elemento, mientras que los elementos OLE predeterminados están inactivos cuando se cargan.

Ejemplo: CVE-2017-11882
La vulnerabilidad CVE-2017-11882 OLE del componente Editor de ecuaciones debido al procesamiento del objeto en un proceso separado hizo posible una operación estable y universal. La etiqueta \ objupdate hizo que Word cargara el componente vulnerable inmediatamente después de abrir el documento.

Ejemplo: elementos incrustados de Excel con macrovirus
Los investigadores han descubierto documentos rtf maliciosos que no utilizan ninguna vulnerabilidad nueva. Los documentos contienen varios documentos de Excel con macros como objetos incrustados. El cálculo se realiza sobre el hecho de que el usuario que, después de abrir el documento varias veces seguidas, se niega a ejecutar la macro, como resultado, "se rinde" y permite la ejecución. Por el momento, la técnica sigue funcionando.

Una diferencia significativa de ActiveX en el caso de elementos OLE incrustados es que el identificador de clase se escribe directamente en el archivo de almacenamiento mediante la función WriteClassStg. Esta técnica se hereda de hace mucho tiempo, cuando Microsoft desarrolló con entusiasmo el concepto de "serialización" y almacenamiento de objetos con su estado en formato CFBF. El documento contenedor también guarda el identificador de clase del elemento implementado, pero se cargará el objeto de la clase especificada en el repositorio. Este identificador se puede reemplazar obligando a la aplicación a cargar un objeto que no está destinado para estos fines.
Es posible editar los datos del elemento, lo que en ciertos casos conduce a la identificación de vulnerabilidades.

Los objetos OLE también se someten a numerosas comprobaciones de descarga, lo que dificulta obtener una lista completa de elementos potencialmente cargados. El conjunto de elementos que se pueden cargar como objetos OLE es diferente de la lista de ActiveX cargados. En particular, se verifican en una lista de KillBit que no es propiedad de Office, sino de Internet Explorer (HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Internet Explorer \ ActiveX Compatibility).

OLE por enlace

OLE distingue entre dos mecanismos para incrustar contenido en un documento: incrustar directamente un documento OLE y crear un enlace dentro de otro documento a otro documento. En caso de incrustar el objeto OLE por referencia, el documento principal contiene una indicación de la ruta al archivo del documento incrustado. La ruta puede ser local o de red, o una dirección de Internet. El controlador OLE está determinado por la extensión del archivo, el controlador correspondiente debe estar registrado en el sistema operativo.

Ejemplo: CVE-2017-0199
La vulnerabilidad de CVE-2017-0199 consistió en la posibilidad de agregar un formato hta "objeto por referencia" al documento. Este último es html con la capacidad de ejecutar código, es decir, en realidad es un archivo ejecutable. El controlador descargó y ejecutó automáticamente hta, lo que le permite ejecutar código arbitrario al abrir un documento.

Antes de actualizar el objeto incrustado, la aplicación solicita permiso del usuario. En este caso, el archivo se descarga por adelantado, lo que puede servir para revelar información sobre el usuario.

Archivos incrustados (paquetes)

Los documentos de Office admiten la capacidad de agregar cualquier archivo (Objeto -> Crear desde archivo o simplemente arrastrar y soltar el icono del archivo en el campo de edición). Técnicamente, esto se implementa agregando un elemento incorporado del Object Packager al documento que escribe el archivo deseado en sus propios datos. Object Packager le permite reemplazar el icono y la firma del archivo, así como especificar la línea de comando para abrir. Puede incluir archivos "por referencia" cuando el archivo se abre no desde su propio almacenamiento, sino a lo largo de la ruta especificada, incluida la red .

Recientemente, la funcionalidad de Object Packager se ha reducido significativamente, e inicialmente el elemento podría guardar cualquier archivo, incluidos ejecutables, enlaces e incluso la línea de comandos. Todo lo que el usuario tuvo que hacer para iniciar el contenido fue hacer doble clic en el icono en el texto del documento.

Ejemplo: archivos en el cuerpo de un mensaje de Outlook
Los mensajes de Outlook, que también son documentos compuestos, le permiten agregar elementos de Object Packager al cuerpo del mensaje . Para el usuario, el elemento parece una imagen seleccionada arbitrariamente por un atacante. Al hacer doble clic en la imagen, se abre el archivo empaquetado. Un atacante tiene que elegir un tipo de datos de aquellos que aún no están sujetos a políticas de seguridad más estrictas .

Elementos en línea no implementados usando OLE

Por el momento, la mayor amenaza / interés de los elementos que no son OLE pueden ser imágenes que se agregan al documento por referencia . Cuando se abre un documento en un modo no protegido, las imágenes se descargan automáticamente, lo que puede conducir a la divulgación de la ubicación e identidad del usuario que descargó el documento a través de servidores proxy anónimos o recibió un documento confidencial de terceros. Esta técnica, en particular, se implementó en la herramienta Scribbles , que está en servicio con la inteligencia estadounidense.
En una red de área local de Windows, la descarga automática de imágenes por referencia permite aprovechar la vulnerabilidad NTLMRelay . El mecanismo para vincular imágenes no es compatible con los requisitos de seguridad de las redes ActiveDirectory, ya que un administrador que recibe dicho documento esencialmente ejecuta un código de atacante con todos los privilegios administrativos.

Métodos de seguridad

Que se puede hacer En general, un poco.

El método más efectivo de protección contra vulnerabilidades en objetos incrustados en documentos de Office es el modo de visualización protegida . En este modo, se excluyen tanto la carga de objetos como la carga de datos de fuentes externas. Desafortunadamente, la transición a un modo con todas las funciones requiere acciones elementales del usuario que son fácilmente provocadas por los métodos de ingeniería social.



Los controles ActiveX se pueden deshabilitar en la configuración del Centro de confianza



Tenga en cuenta que esto no funciona para los elementos en línea OLE.