La lucha de Windows contra la ejecución de código: Éxitos y fracasos (V)

lunes, 15 de octubre de 2018

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, sino 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 de qué técnicas contra la ejecución de código, independientemente de EMET, se han introducido. Porque es cierto que no resulta del todo justo comparar Windows 10 vs EMET, en frío y en una sola dirección. Windows 10 incluye mucho más.

Así que vamos a hablar de novedades concretas de Windows 10, independientemente de lo que fue EMET. ¿Te suena SMEP, SMAP, VBS (Virtual Based Security) o NPIEP?

¡Usuario!, el kernel no se toca: Supervisor Mode Execution Protection
Esta tecnología, aunque relativamente reciente, es en realidad algo de lo que se lleva hablando al menos desde 2008. Pero como requiere de que el procesador y el sistema operativo se pongan de acuerdo para restringir una acción específica de los atacantes, ha tardado algunos años en hacerse realidad. En este caso, SMEP se introdujo ya en los procesadores Intel (desde 2011) y poco después en Windows 8.

Básicamente, impide que desde ring0 se ejecute nada del espacio de usuario (ring3). Se consigue marcando el bit 20 del registro de control CR4 en el procesador para las páginas de usuario, y la CPU impedirá que cualquier cosa en el ring0 (la memoria en el espacio del kernel) llame y ejecute nada que se encuentre en la memoria de usuario, esto es, con el bit activo. Para entender para qué se hace esto, tenemos que ver cómo se produce tradicionalmente un tipo común de elevación de privilegios.
  1. El atacante prepara el shellcode en memoria de usuario… 
  2. ....y luego aprovecha una vulnerabilidad en algo que se ejecute en ring0 (drivers, por ejemplo) y desde ahí redirigir las instrucciones a ese shellcode preparado. 
Para el atacante, es mejor así porque el área de usuario es más "visible", se conocen mejor las direcciones, y reconducir el código ahí es más sencillo que prepararlo todo en la memoria del kernel. Así que toda la idea de SMEP es activar el bit 20 del registro de control CR4 del procesador para esas páginas y evitar que esto ocurra. Si alguien quiere meter un payload en un fallo de ring0, gracias de SMEP tendrá que limitarse a la memoria del kernel. Y ahí abajo es difícil hacer cosas sencillas como crear procesos, acceder a disco, etc.

Fuente: web.archive.com
Esto limita la posibilidad en los escenarios típicos de intento de elevación, pero como siempre ( y como todo) no las elimina. Sin ir más lejos se podría seguir haciendo ROP tradicional en código, bien para eliminar el bit culpable de su activación con ROP ya en memoria de Kernel y luego seguir haciendo lo de siempre, o bien construir todo el payload a base de ROP con trozos de código en el kernel… básicamente igual que pasa con DEP. Pero cuidado. Modificar el CR4 (el registro SMEP) hará que salte PatchGuard... pero PatchGuard (o KPP) siempre ha sido una tecnología trivial de eludir desde Windows XP por jugar en el mismo contexto que el kernel. También habrá que eludir el ASLR de kernel, pero gracias a que HAL.DLL en el kernel  siempre se carga en el misma famosa dirección 0xffffffffffd00000), eso también es fácil.

https://es.slideshare.net/VitalyNikolenko/linux-smep-bypass-techniques
Y ahora, SMAP (Supervisor Mode Access Prevention) que todavía no está en Windows (sí en el resto de sistemas operativos, en este caso será el último y se espera para 2019). SMAP es fundamentalmente lo mismo que SMEP, pero incluso impide no solo la ejecución, sino la escritura (el acceso en general) y lectura en esas zonas de memoria. Si SMEP impide que desde el kernel se tome instrucciones, esto va un poco más allá porque ya no se podría deshabilitar SMEP y hacer "como siempre"… ya no podría ni traer datos de la zona de usuario y ejecutarlos. Es el bit 21 del CR4.

VBS, o la virtualización como elemento de seguridad
Desde que en 2008 se incluyó Hiper-V, el software de Microsoft que aprovecha la capacidad de virtualización nativa de los procesadores Intel y AMD, se han orientado estas funcionalidades para mejorar la seguridad. De hecho, a esta estrategia se le llama Virtualization-Based Security. Se centra en virtualizar memoria para aislar los procesos entre sí al máximo. Imagina que un atacante, eludiendo SMEP, SMAP… intenta explotar un fallo en el kernel y está operando desde ahí. Todavía cabría esperanza y formas de ponérselo más difícil. Podemos operar desde una abstracción todavía superior (o inferior, según se mire) con todavía más poder que el kernel, y prevenir procesos o acceso a ciertos recursos aun cuando se tienen poderes en el ring0. De ahí su utilidad.

Por ejemplo ya se virtualizan procesos críticos de sistema, y de ahí, se derivan a su vez soluciones de seguridad basadas en el hypervisor como Hypervisor-Enforced Code Integrity (HVCI), que se encarga de cuidar que los drivers firmados no pierdan su integridad cuando se lanzan a memoria. El hypervisor tiene todo el poder absoluto sobre el sistema, y se puede encargar a otro nivel de marcar páginas de memoria, evitar que se escriba en páginas ejecutables (integridad a nivel de proceso), etc.
Por otro lado, la capacidad de virtualización (dentro de la estrategia general VBS, esta capacidad se llama Virtual Secure Mode (VSM)) también se utiliza para evitar que ciertas instrucciones (que solo sirven a nivel de kernel), se ejecuten en el espacio de usuario. En el mundo del exploiting, se sabe que si se en algún código se usan SIDT, SGDT, SLDT o STR, algo raro ocurre. Básicamente dos posibilidades:
  • Es un exploit intentando obtener información de las tablas para "situarse" en el espacio de memoria del kernel, conociendo las tablas de descriptores globales o locales, precisamente para arrojar algo de luz en esa zona tan opaca.
  • Puede ser que se intente detectar que se está en una máquina virtual.
Y ninguna de estas dos acciones supone nada bueno. Non-Privileged Instruction Execution Prevention (NPIEP) otra tecnología que lleva Windows 10, permite exactamente eso: evitar que esas instrucciones sean usadas desde el espacio de usuario. Ojo, Intel tiene UMIP, a nivel de procesador, que es muy parecido pero sin necesidad de virtualización de por medio (y esto ya lo soporta de forma nativa el kernel Linux desde este año).

Y para terminar… ¡un Edge completamente seguro! (sí, en serio)
Imagen Esquema de funcionamiento de WDAG
Esquema de funcionamiento de WDAG
Y por poner otro ejemplo de uso de la virtualización para reforzar la seguridad muy reciente, en la última versión de Windows, Edge puede ejecutarse como proceso virtualizado, y aislado. Eso sí, solo en ciertas versiones Enterprise y Pro. La tecnología para conseguirlo se llama Windows Defender Application Guard, y crea un kernel mínimo para ejecutar Edge. La tecnología hermana se llama Windows Defender System Guard y crea un kernel específico para, en general, procesos muy críticos del sistema.

Con Edge virtualizado de serie, no podrás copiar y pegar o descargar a menos que modifiques la configuración imagen
Con Edge virtualizado de serie, no podrás copiar y pegar o descargar a menos que modifiques la configuración
Cuidado, que Edge así es poco práctico. No te dejará subir nada (no tienes acceso a tu sistema de ficheros... de hecho, ahora sabrás para qué sirve esa cuenta misteriosa que aparece con el nombre de WDAGUtilityAccount en el Windows), ni usar el portapapel. Pero se puede cambiar. Arrancan gpedit.msc y ahí tienes las opciones. Sería interesante comprobar si este sistema gana a la "todopoderosa" sandbox de Chrome.

Instalación de Windows imagen
Aquí se pueden modificar las opciones de Edge en modo virtualizado

Y aquí lo dejamos por ahora. En esta entrada nos hemos centrado en las tecnologías aplicadas al punto donde EMET no podía estar, en lo más cercano al procesador y el kernel del sistema operativo. Todas con la estrategia que consideramos adecuada: dificultando siempre la creación de exploits porque las vulnerabilidades… tenemos que dar por hecho que siempre estarán ahí.

» La lucha de Windows contra la ejecución de código: Éxitos y fracasos (I)
» La lucha de Windows contra la ejecución de código: Éxitos y fracasos (II)
» La lucha de Windows contra la ejecución de código: Éxitos y fracasos (III)
» La lucha de Windows contra la ejecución de código: Éxitos y fracasos (IV)

Sergio de los Santos
Innovación y laboratorio de ElevenPaths

No hay comentarios:

Publicar un comentario