Técnicas de mitigación con Microsoft EMET

Microsoft ha publicado recientemente la versión 2.0.0 de su Enhanced Mitigation Experience Toolkit (EMET).

Se trata de un toolkit diseñado para administrar fácilmente las tecnologías de seguridad de mitigación de Microsoft, aplicándolas a través de políticas generales de sistema o bien directamente sobre un ejecutable de una aplicación de terceros. El objetivo final es minimizar el éxito de exploits frente a vulnerabilidades de software, incluido 0-days.

Esta nueva versión viene con un GUI (la versión anterior sólo funcionaba por consola) e incluye dos nuevas técnicas de mitigación: EAF y ASLR.

Sin embargo, EMET podrá aplicar o no todas las técnicas de mitigación dependiendo del sistema operativo donde se instale y de la arquitectura del sistema (32 o 64 bits), tal y como se indica en las siguientes tablas:

A continuación indicamos cada una de las técnicas de mitigación, así como una pequeña descripción de las mismas extraídas principalmente desde el manual de usuario de la propia herramienta:

Structure Exception Handler Overwrite Protection (SEHOP)

Esta medida nos protegerá actualmente contra la mayoría de las técnicas utilizadas para explotar desbordamientos de pila (stack overflow/overrun) en Windows.

Esta mitigación ya fue añadida en Vista SP1 y en Windows 7 donde existe la posibilidad de habilitarla o deshabilitarla por proceso. Con EMET, se añade también esta posibilidad en cualquier plataforma, incluido XP.

Sin ninguna protección, un atacante podría sobrescribir el manejador del puntero de un registro de excepción en la pila, de tal manera que SO saltará y ejecutará su código malicioso.


Con EMET, antes de que el SO llame al manejador de la cualquier excepción, se validará previamente la cadena del registro. Si la cadena es corrupta, EMET terminará el proceso obviando el puntero.


Dynamice Data Execution Prevention (DEP)

DEP puede utilizarse desde Windows XP. Sin embargo, sus opciones de configuración no permiten a las aplicaciones utilizarlo al menos que se compilen con un flag especial. Precisamente EMET permite a las aplicaciones utilizar DEP sin necesidad de recompilarse.

Sin ninguna protección, un atacante podría intentar explotar una vulnerabilidad saltando a un shellcode en una región de memoria que controle un atacante, como la pila o la cabecera, y será posible ejecutar el código malicioso dado que esa región de memoria está marcada como ejecutable.


A través de EMET o activando DEP para un proceso, la cabecera y la pila de memoria serán marcadas como 'no-ejecutables' y cualquier intento de ejecutar código malicioso será denegado a nivel del procesador.


Heapspray Allocations

Cuando un exploit se ejecuta, a menudo no puede asegurarse la dirección donde reside su shellcode y debe encontrarlo cuando se toma el control del puntero de la instrucción. Para incrementar las posibilidades de éxito, la mayoría de los exploits actuales utilizan técnicas de heapspray para grabar copias de su shellcode en tantas localizaciones de memoria como sea posible.


Con EMET, algunas de las páginas de memoria más utilizadas son pre-alojadas. Los exploits que intenten controlar esas páginas (y saltar dentro de ellas) fallarán.


Null page allocation

Es similar a la técnica de heapspray pero previene la resolución de una referencia a nulo en modo de usuario.

Mandatory Address Space Layout Randomization (ASLR)

ASLR ordena de forma aleatoria las direcciones donde se cargan los módulos para prevenir que un atacante pueda situar datos en lugares predecibles. El problema con esto es que todos los módulos tienen que usar un flag en tiempo de compilación para optar a ello.

Sin EMET, un atacante podría tomar ventaja de un mapeo predecible para las dlls y podría usarlas para saltarse el DEP por medio de una técnica conocida como ROP (Return Oriented Programming).


Con EMET, se fuerza a que los módulos se carguen en direcciones aleatorias para un proceso en cuestión, independientemente de si fue compilado o no con el flag. De esta manera los exploits que utilizan ROP e intentan aprovecharse de mapeos predecibles fallarán.


Export Address Table Access Filtering (EAF)

Normalmente un shellcode necesita llamar a las APIs de Windows para hacer algo "útil". Sin embargo, para llamar a una API, el shellcode debe encontrar primero la dirección donde la API ha sido cargada.

Para hacer esto, normalmente todos los shellcodes iteran a través de la tabla exportada de direcciones de todos los módulos cargados en busca de los módulos que contienen las APIs a utilizar. Una vez que se encuentra un módulo interesante, el shellcode luego puede averiguar la dirección donde reside una API en ese módulo.

Lo que hace esta técnica de mitigación es filtrar los accesos a la EAT (Export Address Table), permitiendo o denegando el acceso de lectura/escritura basándose en el código de llamada. Con EMET, la mayoría de los shellcodes actuales serán bloqueados cuando intenten buscar las APIs necesarias para su payload.