La lucha de Windows contra la ejecución de código: Éxitos y fracasos (VI): Attack Surface Reduction

Es complicado entender todo el entramado que está montando Microsoft alrededor de Windows 10, con medidas de seguridad cada vez más integradas y complejas. Es muy positivo, si no fuera porque algunas medidas están adquiriendo una complejidad tal, que para el usuario medio (poco instruido en seguridad), le resultan poco menos que esotéricas, incompresibles y por tanto, inútiles si no están activadas por defecto (que muchas no lo están). Hablamos en esta entrega del ASR: Attack Surface Reduction, que comenzó como un sistema de bloqueo de carga de DLLs en EMET, pero que ahora pretende frenar ataques muy concretos de forma muy específica. No dispone de interfaz gráfica, pero es bastante potente.

Como ya examinamos, ASR se incluyó en EMET 5 en 2014, funcionaba sin interfaz gráfica de manera muy arcaica. Luego se mejoró su fórmula y su manejo, como introdujimos en la primera parte de La lucha de Windows contra la ejecución de código: Éxitos y fracasos.

Vamos a ver ahora en qué consiste exactamente ASR hoy por hoy. ASR engloba ahora mucho más, a falta de una explicación mejor, ASR son una serie de reglas configurables destinadas a mitigar de raíz problemas comunes, relacionados con el hecho de que, desde una tecnología, se llame a otra, reduciendo su superficie de ataque. Por ejemplo, desde Office a las macros, o exploits; o desde el email a scripts, o desde USB a ejecutables no firmados. Así que básicamente, son soluciones muy ad-hoc para ciertas circunstancias y que permite combatir las macros en Office, bloquear scripts, emails, proteger programas peligrosos como Adobe Reader, y la entrada de ejecutables potencialmente dañinos a través de memorias USB. Ahora bien… ¿funciona de verdad?

¿Cómo funciona?

Es sencillo, pero se trabaja principalmente desde la línea de comando de powershell (como administrador). También a través del gpedit.msc, pero en todo caso, siempre debemos conocer los GUIDs.

Microsoft nos propone una serie de GUIDs, cada uno correspondiendo a una medida. En un principio, sobre 2016, eran muy pocas; pero en cada nueva versión de Windows 10 se han incorporado nuevas. Actualmente se pueden personalizar 14 reglas de reducción de superficie de ataque, daremos una breve explicación propia de cada una de ellas  y comprobaremos si funcionan o no. En esta entrada evaluaremos tres de ellas.:

 Por supuesto, siempre leedlo en inglés. En castellano lo más probable es que no tenga ningún sentido. Ojo, no confundir con esta funcionalidad genérica de los antiexploits que se muestra en la imagen.

Esta receta de ASR aplica solo a Office, mientras que en la configuración de antiexploits, podría incluirse cualquier programa. Por experiencia personal, sabemos que aplicar esta receta ASR en Office permite trabajar con él, mientras que evitar de forma genérica los procesos secundarios en Word, por ejemplo, hará que el procesador no funcione correctamente. Para activarla, sería necesario ejecutar en un powershell con privilegios de administrador:

Add-MpPreference -AttackSurfaceReductionRules_Ids D4F940AB-401B-4EfC-AADC-AD5F3C50688A -AttackSurfaceReductionRules_Actions Enable

Carlos Pérez realizó hace algún tiempo un análisis sobre Block All Office applications hablando de qué bloquea y qué no bloque esta receta.
Hemos reproducido parte de sus experimentos y al parecer no han variado nada en la última versión de Windows 10. Por ejemplo, esta receta bloqueará estas macros:

Pero se le escapa cualquier proceso creado a través de WMI. Esta macro, por ejemplo, no es bloqueada:

Lo que hace totalmente inútil esta regla… Hasta ahora, porque luego veremos que Windows creó una regla específica para impedir esta ejecución, pero lo hizo meses después en una segunda tanda de GUIDs.

Pero volvamos a esta regla en particular, por sí misma, es poco potente. Hay que recordar que ni la propia herramienta de prueba que realizó Microsoft para comprobar su eficacia, era capaz de bloquear un simple ataque. Hace un tiempo, Microsoft anunciaba una herramienta (muy cutre) realizada en .NET y llamada ExploitGuard Demo que permitía evaluar la eficacia de ASR. Se basaba en establecer las reglas y la herramienta simulaba una serie de ataques de prueba. En aquel momento solo existían algunas de las recetas de ASR de las que disponemos hoy, en concreto, cuando esta herramienta simulaba la ejecución de un proceso para que la regla D4F940AB-401B-4EfC-AADC-AD5F3C50688A, lo detuviese, no lo conseguía.

Desde que le indicamos esto a Microsoft, han retirado la página donde se anuncia la herramienta, pero aún es visible en archive.org.

Esta regla bloquea la importación de las API desde una macro, algo bastante común entre el malware de macro, puesto que habitualmente necesitará llamar a APIs del kernel (u otras librerías útiles) para completar el ataque. Esta, al contrario que la anterior, es una de las reglas más eficaces contra el malware de macro: es sencilla de implementar, no sabemos aún cómo eludirla y realmente supone un problema para los atacantes.

Por ejemplo en la siguiente macro, la detendrá por la importación de la función del kernel, no por la llamada.