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

lunes, 23 de julio de 2018

Es complicado entender todo el entramado de seguridad 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, incomprensibles y por tanto, inútiles si no están activadas por defecto (que muchas no lo están). Nos encontramos así con que buena parte de la cuota de mercado (usuarios "medios") a los que va destinado el propio sistema operativo, no va a comprender o saber aprovechar estas ventajas. Si nos centramos en perfiles más profesionales (administradores de directorio activo y entornos corporativos), el problema es que… probablemente los administradores tampoco tengan tiempo de configurar correctamente el sistema o resulte excesivamente intrusivo (y tampoco tienen tiempo para pruebas de ensayo y error en producción). En este sentido, cabe plantearse incluso si de verdad (hoy por hoy) Windows 10 es la versión predominante en sistemas de escritorio de empresas y este perfil podría aprovechar estas técnicas. Pero veamos cuáles son estas técnicas actuales.

¿Cómo hemos llegado hasta aquí?
El saber popular afirma desde los 90 que Windows es un desastre en seguridad. Como todo saber popular, resulta conflictivo contradecirlo. Lo que sí se puede afirmar es que Windows 10 es el sistema con más medidas de seguridad integradas de serie. Y destaca especialmente en las medidas concretas que sirven para evitar la ejecución de código. A saber: MemGC, CFG, DEP, CIG, ACG, ASLR, CES, IAF… y derivadas son algunos ejemplos. Este es el hecho "en frío". Veamos ahora si sirven para algo, si resultan un mero festival vacío de acrónimos, si las tenemos activadas de serie, si las entendemos… Porque por ejemplo, recientemente Microsoft dejó de pagar por fallos encontrados en CFG, una tecnología que parece que no ha resultado tan útil como esperaban. 

changes to the mitigation bypass bounty scope imagen
Ya no pagan más por encontrar fallos en CFG... "comprendieron sus limitaciones"
 
Así que con éxitos y fracasos, desde el lejano Windows XP, lo cierto es que la lucha contra la "ejecución de código no solicitado" (entre otros frentes abiertos) en Microsoft ha traído bastante innovación a Windows 10, y con ello fusiones de herramientas (unas más útiles que otras), tecnologías, reorganizaciones de configuración y un largo etcétera que pasamos a analizar.

Las motivaciones
Vulnerar un sistema operativo es un fin para los analistas (mejoran, obtienen reconocimiento, ganan los "bounties"…), pero para los atacantes es solo un medio. Lo harán si consideran interesante el mercado que pueden alcanzar con ello. Windows es un jugoso objetivo (por varias razones) y por ello está sometido a un duro escrutinio por parte de los atacantes, que consiguen maximizar beneficios rompiendo su seguridad. Y no solo los creadores de malware, sino los que diseñan de ciberarmas de espionaje. Y estos últimos tienen además los recursos suficientes como para hacer un trabajo incluso más fino que los creadores de malware (que de por sí, no lo hacen nada mal). Tras muchos años de ataque (y los que quedan) Microsoft cuenta ya con un bagaje suficiente como para saber cuál es uno de sus mayores problemas en seguridad: la ejecución de código. Las vulnerabilidades van a estar siempre ahí, y la única posibilidad es intentar que no se aprovechen por atacantes. 

Así, además de intentar crear software con menos vulnerabilidades, se intenta que no se exploten las que van a existir se quiera o no. Para explotarlas es necesario crear exploits, y las técnicas para conseguirlo, al menos, son finitas. Una aproximación más llevadera que las técnicas de detección de malware, que es como barrer el desierto. Microsoft lleva tiempo intentando luchar contra la raíz de la ejecución de código, los exploits y cómo funcionan en memoria. Una estrategia muy interesante que se materializó con EMET, un experimento que ha acabado "integrado" en Windows 10.

EMET, el comienzo
En 2009 apareció EMET. Una herramienta "outsider" de la propia Microsoft pero apoyada y refrendada. Fue diseñada por un creador de exploits con la premisa de detectar las técnicas habituales de construcción de exploits en memoria. Un proyecto que pronto se demostró muy interesante y útil. Todo un éxito y un campo de experimentación que permitió la situación actual. EMET se inyectaba en los procesos como DLL y vigilaba que nadie explotara en ese proceso una vulnerabilidad usando las técnicas sospechosas habituales. Evolucionó hasta su versión 5.5 (que será la última), donde ya incluía protecciones muy interesantes más allá de las capacidades "antixploit" como ASR, certificate pinning, protección contra fuentes potencialmente daniñas… maduró bastante y, aunque alguna que otra vez se le encontraron problemas, resultaba una aproximación muy interesante contra la ejecución de código. Porque malware habrá millones, pero las técnicas de explotación son finitas. Se intuía que acabaría en el sistema operativo. Al principio (2016), se dio a entender que EMET ya no era necesario en Windows 10. En aquel momento todavía no incluía todo el potencial de EMET, pero las cosas han cambiado. Ahora podemos decir que tenemos Windows Defender Exploit Guard, un buen heredero de EMET… y un paraguas anti-explotación y anti-ejecución en Windows 10. Vamos a centrarnos en la parte de anti-explotación de esta tecnología.

EMET, configurado con programas protegidos imageb
EMET, configurado con programas protegidos por más de una docena de técnicas típicas de creación de exploits

De EMET a Windows Defender Exploit Guard
Windows Defender Exploit Guard son muchas cosas. Toda esta tecnología se engloba dentro de lo que Microsoft llama Windows Defender, que muchos todavía identifican erróneamente en exclusiva con el antivirus. Como muchos antivirus, Windows Defender es ya una especie de Endpoint Security que incluye mucho más que la estricta detección de malware. La tecnología específica de Windows Defender para evitar los exploits es "Exploit Guard". A su vez, dentro de esta tecnología, Exploit Guard aborda cuatro puntos de control:
  • Exploit Protection
  • Attack Surface Reduction
  • Network Protection
  • Controlled Folder Access 
En esta serie de artículos, nos vamos a centrar en la protección contra exploits. Pero para terminar con esta primera parte, resumimos el resto de puntos.

Attack Surface Reduction: ASR
Durante 2013, fue necesario "detener" la locura de exploits y problemas de seguridad que aparecían en el plugin Java que utilizan la mayoría de los navegadores. Casi todos acabaron desactivándolo por defecto. Poco después, Flash o Siverlight fueron los objetivos primordiales para llegar a la víctima a través del navegador. En 2012, EMET incorporó una interesante funcionalidad llamada Attack Surface Reduction (ASR) que suponía una importante mejora para la seguridad porque bloqueaba selectivamente la llamada a los binarios que interpretaban estos plugins.

El ASR de EMET imagen
El ASR de EMET "original". Ya poco tiene que ver con esto
Pero eso quedó atrás y poco tiene que ver lo que Microsoft llama ASR ahora. El navegador Edge ya "se defiende solito" (principalmente porque bloquea por defecto buena parte de los plugins y tecnologías potencialmente peligrosas). Ahora ASR engloba mucho más. En concreto ASR son ahora una serie de reglas configurables destinadas a mitigar de raíz el hecho de que, desde una tecnología, se llame a otra, o sea, reducir su superficie de ataque. Por ejemplo, desde Office a las macros, o exploits, o desde el email a scripts. Básicamente, ASR permite:
  • En Office: combatir principalmente el mayor enemigo actual que son las macros.
  • En los Scripts: bloquear los Powershell, JavaScript y VBScrip potencialmentes dañinos lanzados por otros programas.
  • En los emails: ASR son también reglas configurables específicas para bloquear el contenido potencialmente descargado desde el cliente nativo de correo de Windows. 
Todo esto se analiza y se implementa a través del propio Defender (que obviamente debe correr en tiempo real). Son como "plugins" adicionales para proteger mejor otros programas que pueden lanzar a su vez código malicioso cuando son explotados. Hablaremos de ASR en otras entregas, porque es más complejo de lo que parece.

Network Protection
Esta tecnología es sencilla de explicar. En las versiones Enterprise de Windows 10 bloquea directamente el acceso a dominios sospechosos desde cualquier proceso. ¿Y qué es sospechoso? Lo que detecte a su vez SmartScreen como dañino, que ya lo conocemos de antes. Es una especie de “Cortafuegos dinámico” para Windows, que bloqueará los dominios sospechosos desde todo el sistema (no solo en el navegador, como ahora), de forma dinámica y con heurística (no es solo una lista negra). Así evitas que un proceso malicioso llame a un dominio que SmartScreen considera dañino. Si no tienes Network Protection, en otros Windows, SmartScreen te protegerá (mejor o peor) de los dominios por los que navegas.

Controlled Folder Access
Otra fórmula sencilla específicamente diseñada contra el ransomware. Puedes indicar que quieres que ciertas carpetas sean protegidas para que su contenido no se modifique. En realidad no es mágico. Todo pasa de nuevo por el hecho de que los ejecutables que acceden al contenido de esa carpeta se consideren "de confianza". Hay una lista blanca de programas de confianza que pueden acceder (Office, por supuesto, y otros nativos del sistema operativo), y el resto, no deberían poder llegar a modificar ese contenido.

Exploit Protection
Y por último, lo que creemos que es más interesante: la protección contra exploits, la consecuencia de EMET más directa y que incluye tecnologías como MemGC, CFG, CIG, ACG, CES, IAF y por supuesto DEP y ASLR… ¿Sirven para algo en realidad? ¿Qué significa este festival de acrónimos? ¿Éxitos o fracasos? Lo veremos en la siguiente entrega.

Sergio de los Santos

No hay comentarios:

Publicar un comentario