volvervolver
Follina, un Client-Side silencioso

POR:
Mariano Quintana
CYBERSECURITY TRAINER & RESEARCHER

COMPARTIR

Twitter Facebook Linkedin
REFERENCIAS

Argentina.gob.ar:https://www.enisa.europa.eu...

https://www.cyberark.com/...

ENISA Threat Landscape

Follina, un Client-Side silencioso

Se ha hablado mucho sobre la ya famosa vulnerabilidad denominada Follina, reportada como Zero-Day a principios de este año y denominada también con su nombre más técnico como CVE-2022-30190, asociada particularmente al protocolo URL de Microsoft Support Diagnostic Tool (MSDT) considerada por la mayoría de los equipos de DFIR como “un gran dolor de cabeza” debido a su comportamiento inusual. En la mayoría de los casos en donde se reciben ataques utilizando herramientas de Microsoft Office, los equipos suelen dar por sentado que ocurren a través de los métodos más conocidos, como por ejemplo el uso de las famosas Macros, teniendo ya ensayadas protecciones para estos mecanismos habituales utilizados en los ataques del lado del cliente (Client-Side)

¿Qué ocurre cuando nacen nuevos caminos para realizar lo mismo? ¿Están los equipos de respuesta ante incidentes lo suficientemente maduros para adaptarse a las nuevas formas de los atacantes? La realidad es que cada día con mayor frecuencia estos equipos de respuesta ante incidentes deben actualizar sus procesos y mecanismos, más aún cuando se trata de la utilización de servicios válidos acoplados al funcionamiento normal de nuestro sistema operativo.

Si bien se estima que se viene ejecutando desde abril, a finales de Mayo fue detectado por primera vez y subido a virustotal un documento extraño con la nomenclatura 05-2022-0438.doc, el investigador bautizó a esta muestra Follina, debido a que el número 0438 es el código postal de la localidad italiana Follina, Treviso. El reporte indicaba la posibilidad de ejecutar código a través de Office aprovechándose del servicio interno MSDT de Windows (AKA solucionador de problemas), encargado de recopilar información de diagnóstico para enviarla a Microsoft en caso de que ocurra algún tipo de error.

Seguramente al estar leyendo este post se preguntarán cómo un atacante puede aprovecharse de esa falla si la misma se debe ejecutar del lado del cliente. Para entender esto veamos una breve explicación.

Cómo funciona un ataque Client-Side

Si la PC de la víctima fuera nuestro hogar por lo general tendría las puertas cerradas y la llave de la casa para poder abrir las mismas y dejar pasar a las personas. Por lo que el objetivo del atacante sería lograr que alguien desde adentro le abra la puerta para poder pasar sin ningún tipo de inconveniente. Ahora bien ¿Cómo logra un atacante que le abran la puerta de una casa? La principal estrategia utilizada es el uso de la ingeniería social, para convencer a la víctima de que la misma se abra. Para ello, el atacante busca un canal común en el que la víctima confíe y luego, con distintas estrategias, convence a la misma de ejecutar un archivo o hacer clic en algún enlace provisto a través de este medio en común (generando la acción de apertura desde adentro).

imagen ilustrativa

Si bien el ejemplo gráfico es absurdo (aunque muchas veces funciona con éxito) cuando hablamos de sistemas informáticos, reemplacemos la pizza por una necesidad latente que implique por ejemplo descargar un documento de Microsoft Word para completar algún formulario o leer algún tipo de información de interés para la víctima y listo del lado del cliente estamos abriendo la puerta que el atacante necesita.

Funcionamiento de Follina como Client-Side

Teniendo en cuenta el ejemplo anterior, se envía un documento de Office (en este caso Word) hacia la víctima. Ese documento de Office va a estar creado de tal forma que genere un error para poder invocar el servicio de solución de problemas de Windows que comentamos más arriba, denominado MSDT.exe. Una de las primeras versiones de este malware se comportaba de la siguiente manera:
imagen ilustrativa

Es decir, el archivo de word (nuestra pizza), ejecutado por la víctima, llamaba a un archivo HTML y descargaba código malicioso ejecutándose a través de PowerShell.

¿Pero por qué ocurre esto? Los archivos tienen la posibilidad de adjuntar información adicional en determinadas variables del mismo, a modo de aportar variables cosméticas que se relacionan directamente con el documento. Ej; Si utilizamos el comando 7z para descomprimir el archivo de Word, podríamos visualizar el contenido adicional que tienen los mismos.
imagen ilustrativa

En este caso particular el documento usa la función de plantilla remota de Word (Word/_rels) para recuperar un archivo HTML alojado en el servidor del atacante, dicho extracto usa el esquema de instrucciones "ms-msdt" para cargar código y ejecutar comandos a través de PowerShell.

Si nos ponemos a pensar, todas son herramientas provistas por el sistema operativo, salvo la construcción de nuestro exploit. Para aportar más claridad a continuación utilizaremos una prueba de concepto (PoC) a fines de demostrar el funcionamiento de la vulnerabilidad. Nuestro escenario se compone de un Kali Linux, en donde construiremos nuestro payload. Y un Windows 10, con el correspondiente pack de Microsoft Office instalado.

En el siguiente gráfico podemos apreciar cómo sería el escenario correcto

  1. El atacante envía el archivo malicioso

  2. La víctima ejecuta el archivo

  3. La víctima va a buscar el HTML con las correspondientes instrucciones

imagen ilustrativa

Escenario de Prueba

  - En primer lugar clonaremos este repositorio de github con el comando gitclone del repositorio: https://github.com/JohnHammond/msdt-follina imagen ilustrativa

  - Luego comprobamos que se haya clonado correctamente: imagen ilustrativa

  - Procederemos ahora a crear nuestro primer payload, con el comando python3 follina.py --port [Puerto a elección] , en la captura de pantalla anterior observamos que el script utilizado deja un payload HTML, en el puerto que hemos seleccionado previamente:

imagen ilustrativa

  - Si queremos observar cómo se verían las peticiones realizadas por parte de la víctima en tiempo real, podríamos realizar un wget http://localhost:5555/ y visualizar en el log de nuestro script todas las peticiones realizadas.

imagen ilustrativa

  - Luego copiamos el documento generado follina.doc desde la carpeta en la que se alojó en nuestro caso /root/msdt-follina (Para simular el envío del mismo) Luego lo trasladamos a nuestra máquina virtual con Windows 10:

imagen ilustrativa

  - Procedemos a ejecutar el archivo correspondiente, luego de haberlo ejecutado podemos observar como se abre el servicio MSDT.exe y adicionalmente se ejecuta la instrucción de abrir la calculadora.

Cómo defenderse

Si bien en los orígenes de estos problemas, lo único que nos quedaba era deshabilitar el servicio msdt.exe, es muy importante al día de hoy que tengamos nuestros sistemas operativos actualizados. Ya que si no tenemos un correcto seguimiento de los parches habituales de seguridad, puede estar allí nuestro principal punto de debilidad.

Dentro de los parches se encuentran los siguientes Knowledge Base (KB), a tener en cuenta;

KB5014678: Windows Server 2022
KB5014697: Windows 11
KB5014699: Windows 10 Version 20H2 – 21H2, Windows Server 20H2
KB5014692: Windows 10 Version 1809 (IoT), Windows Server 2019
KB5014702: Windows 10 1607 (LTSC), Windows Server 2016
KB5014710: Windows 10 1507 (RTM, LTSC)
KB5014738: Monthly Rollup Windows Server 2012 R2, Windows RT 8.1, Windows 8.1
KB5014746: Security only Windows Server 2012 R2, Windows RT 8.1, Windows 8.1
KB5014747: Monthly Rollup Windows Server 2012
KB5014741: Security only Windows Server 2012
KB5014748: Monthly Rollup Windows Server 2008 R2, Windows 7 SP1
KB5014742: Security only Windows Server 2008 R2, Windows 7 SP1

En el caso de que se encuentren en la situación de no poder aplicar parches debido a imposibilidad de actualizar los sistemas o en su defecto debido a errores en la gestión de actualizaciones. Se podría darle un tratamiento a la falla de la siguiente manera: aplicar una regla ASR (Attack Surface Reduction) con Windows Defender, en donde se bloqueen las aplicaciones de Microsoft Office para que las mismas no creen procesos secundarios.

Ejemplo:
  - Add-MpPreference
  - AttackSurfaceReductionRules_Ids   - 4f940ab-401b-4efc-aadc-ad5f3c50688a   - AttackSurfaceReductionRules_Actions Warn | Enable Deshabilitar el protocolo url de MSDT modificando la siguiente clave de registro:
  - Crear copia de seguridad; “reg export HKEY_CLASSES_ROOT\ms-msdt filename”
  - Ejecutar el comando “reg delete HKEY_CLASSES_ROOT\ms-msdt /f”

Conclusión

Como ya vimos en este artículo, todos los ataques que conocemos evolucionan con el paso del tiempo. Es posible también que estas noticias se hayan recibido a principio de año y ya tengan o no actualizada su infraestructura. Lo más importante es que a pesar de ello nunca le perdamos pisada a este tipo de cuestiones ya que pueden llegar a existir variantes del mismo que puedan perjudicar ampliamente la infraestructura personal o de la organización.

Más allá de eso, nunca se debe perder de vista la importancia del entrenamiento de los equipos de seguridad de la organización para que día a día tengan un entrenamiento adecuado a la hora de ejecutar contramedidas y soluciones. La mejor defensa contra los Zero-Day siempre va a ser un equipo de personas con la mayor resiliencia posible ante cualquier evento desafortunado.

«Incluso la mejor espada si se deja sumergida en agua salada finalmente se oxidará». (El arte de la guerra, Sun Tzu)