Ideas, información y conocimientos compartidos por el equipo
de Investigación, Desarrollo e Innovación de BASE4 Security.
Argentina.gob.ar:https://www.enisa.europa.eu...
https://www.cyberark.com/...
ENISA Threat Landscape
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).
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:
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.
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
Escenario de Prueba
- En primer lugar clonaremos este repositorio de github con el comando
gitclone del repositorio: https://github.com/JohnHammond/msdt-follina
- Luego comprobamos que se haya clonado correctamente:
- 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:
- 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.
- 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:
- 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)