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

lunes, 3 de septiembre 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 que se introdujeron con EMET han sido completamente “absorbidas” por el sistema operativo, de forma que no es necesario ningún tipo de configuración adicional para disfrutarlas.

A principios de 2016, Microsoft daba a entender que mataba a EMET, pero que Windows 10 suplía casi todo lo que ofrecía esa herramienta. No es del todo cierto hoy, aunque era aún menos cierto entonces. Se justificaba con frases tales como que Windows 10 disponía de funcionalidades mejores o equivalentes a EMET como Device Guard, CFG y AppLocker. Esto era comparar huevos y castañas. Device Guard es una especie de AppLocker muy avanzado, e impide la ejecución de software desconocido. ¿Qué tiene eso que ver con la mitigación de exploits? CFG sí que absorbe algo de EMET… pero esto requiere una explicación mucho más detallada porque, ¿cómo se combaten las técnicas de creación de exploits actualmente?, ¿cómo se implementan las técnicas anti-rop en un mundo sin EMET?, ¿qué se gana y qué se pierde con Windows 10 sin EMET (porque recordemos que bloquearon su ejecución en este sistema operativo)?


comparación de funcionalidades en una dirección imagen
Tabla obsoleta
Hace algún tiempo, se hizo una comparación de funcionalidades en esta dirección, donde fundamentalmente se podría extraer este cuadro como resumen y resultado.

Pero esta tabla ya está obsoleta (además de no ser totalmente exacta según Ionescu). Existe otra comparación de “Windows Defender Exploit Guard” contra EMET, menos técnica, que Microsoft muestra aquí, y en la que se preocupan de que bajo la columna de EMET, aparezcan más aspas rojas comparando peras y manzanas. Lo más parecido a la comparación anterior la realizó en 2017 Microsoft (con una apariencia sospechosamente parecida), donde dibujó su propia tabla “técnica” comparando EMET con las funcionalidades de Windows 10.

tabla “técnica” comparando EMET con las funcionalidades de Windows 10 imagen
Tabla más reciente, pero obsoleta
Aquí parece que Windows 10 sin EMET no “pierde” tantas cosas, apenas 7 funcionalidades. Pero, teniendo en cuenta que esta información viene del propio fabricante, siempre es conveniente mirarla con lupa. Es más, también está obsoleta, puesto que se introdujeron bastantes cambios con la versión 1709 (Falls creators update). ¿Es bueno, es malo… debería darnos igual? Empecemos explicando los conceptos, diferenciando lo que ya trae Windows 10 de serie, qué no trae, y si es realmente importante o no.


Lo que ya trae Windows 10 de serie
  • DEP: Los principales fabricantes de procesadores acordaron hace ya muchos años que, para intentar impedir los típicos desbordamientos que inundaban la parte de la pila de datos con código, había que dejar claro en el procesador qué son datos y qué es código, en memoria. Puesto que el atacante inyecta código a través de una variable (datos), si se diferencian bien estas páginas (se hace a través de un bit) en memoria, el atacante quizás pueda inyectar código, pero no podrá “ejecutarlo” porque el procesador no le dará “permiso”. Así que, como si de permisos en ficheros se tratara, se incluyó en los procesadores (aproximadamente desde 2005) tecnología capaz de marcar páginas de memoria como “no ejecutables” si se lo dice el sistema operativo. Cada fabricante llama a esta tecnología de una forma. AMD lo llama NX (No-eXecute page protection), ARM lo llama XN (eXecute Never) e Intel XD (eXecute Disable bit). Como curiosidad, en la BIOS podréis ver fórmulas diferentes para activar o no esta opción. Así, Intel utiliza a veces la terminología DEP (Data Execution Prevention) en sus BIOS para referirse a la activación de XD. AMD a veces lo llama “Enhanced Virus Protection”, una desafortunada terminología que sólo puede confundir al usuario cuando lo que se quiere decir es que se hace uso del bit NX. Eludir DEP (junto con ASLR) es lo fundamental que hace un atacante para intentar ejecutar código por culpa de una vulnerabilidad. Muchas de las tecnologías en la tabla de arriba tratan de evitar que un atacante se salte DEP a la hora de crear un exploit. Más concretamente, luchan contra lo que podríamos llamar “la criptonita” de DEP, esto es las técnicas ROP.
  • ASLR: Lo que hace ASLR es que esa dirección de carga de las DLL de sistema cambie en cada reinicio de cada máquina, independientemente de la dirección “image base” definida en el binario. Y no sólo a las DLL de sistema, cualquier DLL o EXE puede utilizarse para buscar direcciones de retorno o direcciones de APIs necesarias para un exploit. De forma que el método se ocupa de cargar los procesos en espacios más o menos aleatorios, de forma que no pueden ser predichas de forma sencilla. Al menos, un atacante tendría que probar un número significativo de valores (mejorados en los últimos Windows con mayor entropía) para poder acertar con la dirección adecuada. Incluso así, este valor no sería el mismo en cualquier otro sistema Windows, por lo que un sistema automatizado de ataque (o sea, un gusano) tendría que adivinar en cada sistema atacado la dirección concreta. Es la razón por la que no se estilan ya gusanos como Sasser o Blaster. Si ha existido Wannacry en 2017 es porque el fallo que aprovechado no necesitaba explotar una vulnerabilidad en concreto, sino más bien era un grave problema de diseño.
¿Y dónde colocas ese código del proceso que se va a lanzar? A veces ASLR no es totalmente aleatorio en ciertas aplicaciones. Esto se mejora con BottonUp ASLR (que lo introdujo EMET). La dirección base del código que una aplicación coloca en memoria se calcula de tres formas: bottom-up (VirtualAlloc, por defecto) busca zonas libres desde abajo a arriba, top-down (VirtualAlloc si se llama con MEM_TOP_DOWN, busca de arriba abajo), o “based” si a VirtualAllo se le pasa una dirección concreta. Desde Windows 8, lo que se hace es empezar en puntos aleatorios a buscar (hacia arriba, o hacia abajo, según el caso) el hueco en memoria para colocar el código. Cuando se añade bottom-up randomization, no solo se elige una base diferente cada vez, sino que se empieza a buscar de forma aleatoria el hueco, para que no siempre quede el mismo y sea más impredecible. Por tanto se añade entropía. Pero ojo, que bottom-up randomization depende de que la aplicación quiera ASLR explícitamente.

forzar opciones como ASLR imagen
Desde aquí se pueden forzar opciones como ASLR y sus variaciones
a diferentes aplicaciones aunque no opten a ello

Recordemos que los ejecutables eligen ser aleatorizados al lanzarse, y todo lo que se compile con VisualStudio desde 2010 lo tiene marcado por defecto. Existe la opción de hacerlo “mandatory” para todas las aplicaciones, aunque no opten explícitamente a ello. Esto se podía con EMET y con Windows 8 y 10, claro. Y además esto se puede hacer para todo el sistema, o por aplicaciones.

  • SEHOP, Structure Exception Handler Overwrite Protection: Sobrescribir la SEH se ha convertido en casi un estándar a la hora de ejecutar código. Según indica la propia documentación de EMET, el 20 % de los exploits de Metasploit utilizan esta técnica. Esta protección está incrustada desde Vista. Con esta directiva activada, Windows previene que se sobrescriban los registros de manejadores de excepción. Desde 2008 y Windows 7, además, puede activarse a nivel de proceso y no solo a nivel de todo el sistema. Para conseguirlo, se puede añadir esta rama del registro por programa y establecer dentro la directiva DisableExceptionChainValidation como DWORD con valor 0.
  • Pinning: EMET permitía realizar pinning para Internet Explorer. Fue un tímido intento, pero que no prosperó. Para ser justos, es cierto que lo que dicen que ahora sirve para “pinear” es horrible desde muchos puntos de vista. Enterprise Certificate, se llama y es de todo menos intuitivo.
  • Fonts: Desde que Windows decidió (cuando escaseaban los recursos) integrar algunas partes de su interfaz en el kernel, muchas funciones gráficas suponen un riesgo adicional. Desde entonces, son cientos las vulnerabilidades que han permitido elevar privilegios cargando fuentes mal formadas, debido a algún fallo al ser procesadas con el Graphics Device Interface (GDI). Esto permitía que, aunque se abriese un documento o se navegara a veces con los mínimos privilegios, al procesar una nueva fuente y aprovechando una vulnerabilidad, se llegase a ejecutar código con mayores privilegios. Esta mitigación permite bloquear la carga de fuentes que no estén ya en el directorio de sistema %windir%/Fonts. Se bloquea todo por defecto, y luego se permite crear excepciones por programa. Se introdujo en EMET pero solo para Windows 10 (que ya la traía de serie).
  • Nullpage: Esta técnica impide que se utilice una página nula como dirección de memoria virtual. Es también una técnica habitual para lanzar un exploit, gracias a los fallos de “null pointer dereferences”. EMET bloqueaba esa dirección para que no pudiera ser usada por un exploit, pero Windows 10 ya lo hace por defecto. Así, los 64 kilobytes de cada proceso quedan reservados exclusivamente para el sistema, y no se puede sobrescribir esa parte.
  • LoadLib: El shellcode necesita habitualmente cargar librerías para tener acceso a APIs de sistema. Lo que hace esta mitigación es que, cuando se llama a las funciones que permiten cargar librerías, se intenta comprobar que son válidas y no vienen de un shellcode. EMET lo hacía y fue incorporado a Windows 10.
  • Memprot: Es como un doble DEP. Aunque se usen técnicas ROP para eludir DEP, memprot intentará comprobar si se ha conseguido (llamando a VritualProtect con técnicas ROP), marcar la pila de datos como ejecutable o sea, si se ha conseguido eludir la protección DEP. De nuevo, EMET introdujo esta mitigación y más tarde fue incorporado a Windows 10.

Atención, para que estas dos últimas tengan sentido, el programador debe haber compilado las aplicaciones para que así sea.

opciones de seguridad a los procesos imagen
Desde aquí se pueden forzar muchas de estas opciones de seguridad a los procesos,
como se hacía con EMET en su momento

Lo que trae Windows 10 a partir de 1709 (Falls Creator Update, de octubre de 2017)
Estas funciones, las tenía EMET y solo aparecen en los últimos Windows 10. Si bien esta comparación no es totalmente justa (quizás habría que incluir otras funcionalidades de Windows 10 que EMET no traía), vamos a explicar qué se han dejado para el final. Antes de introducirlas explícitamente, alegaban que estas tres no hacían falta porque CFG lo suplía. Bueno, no es del todo cierto porque CFG está roto. De hecho aun así las han introducido finalmente. Esto sirve para forzar y proteger aplicaciones que no estén compiladas con CFG.
  • SimExecFlow: Básicamente, se encarga de mirar en las instrucciones un poco hacia delante en el código por si hay muchos “returns”, lo que indicaría que se están usando técnicas ROP. Simula el flujo de ejecución para intentar “ver” técnicas extrañas.
  • Caller: También mira en las instrucciones alrededor del return (antes de que se llama a una API considerada crítica) para asegurarse de que hay un call previo y no un RET o JMP, típico del shellcode
  • Stackpivot: Lucha contra la técnica habitual de mover el puntero de la pila adonde se quiera a la hora de crear un exploit. ESP debe mantenerse dentro de unos límites lógicos, y si se sale, algo extraño ocurre. De nuevo, esta técnica se enmargca dentro de una especie de “predictor” de código parecido a exploits.

 EAF: Otra técnica para creator Update
Nuevas opciones en Falls Creator Update
  • EAF: Otra técnica para crear exploits sin que le estorbe el ASLR. El shellcode normalmente accede a la Export Table de una librería e intenta resolver la dirección de las API, habitualmente GetProcAddress. Export Address Table Filtering (EAF) y EAF+ son técnicas que incluyó EMET que pretenden filtrar ese acceso, para que no cualquiera pueda llegar a una DLL y pedir la dirección de esas funciones necesarias para ejecutar el código. Aparecieron varios trucos para eludirla: por ejemplo, acceder a la Import Table de una librería que se importe en cada proceso. El propio Microsoft avisaba en general de que EAF es un método de protección "débil" por sí mismo. Esta es curiosa porque según la propia Microsoft, no se ha implementado.
    Aunque se pueden encontrar otra documentación donde sí se admite que se ha hecho. En la versión en español parece que se han equivocado con las siglas...
Versión en español imagen


Versión en ingles imagen
Versión en español (mal traducida) y versión en inglés
 
Lo que todavía no trae Windows 10
  • HeapSpray: EMET protegía también contra el Heap Spary, que a su vez es una técnica de creación de exploits para intentar eludir ASLR. Consiste en rellenar una parte de la memoria con el propio shellcode, porque después del salto a una DLL conocida, no se puede estar completamente seguro de dónde aterrizará el puntero de instrucciones, así que en cuántos más sitios pueda colocar su código, más posibilidades de acertar. 
  • EAF+: EAF+ es exactamente lo mismo que EAF pero con una lista negra de librerías predefinidas y solo en principio solo estaba en Internet Explorer. Flash.ocx por ejemplo, estaba en la lista negra, por tanto al atacante no le vale con eludir EAF con las múltiples técnicas conocidas, sino que para explotar esa librería necesitaría que la librearía donde quiere apoyarse no estuviese en la lista negra. En realidad sí parece estar implementado bajo el comando "EAFModules : {}", pero parece estar totalmente "hardcoded", de forma que no parece configurable (solo por línea de comando) ni parecen haber incluido ningún dato por defecto.
¿Entonces en qué quedamos?
Como era lógico, Windows 10 ha seguido esta estrategia:
  • Incorporar rápidamente de EMET las mitigaciones antiexploits que menos problemas y mejor resultado han dado.
  • Incorporar en Windows 10 otras nuevas más fáciles de desarrollar y más eficaces desde el propio core del sistema (no tan sencillo a través de EMET).
  • Ha dejado las experimentales para lo último, o incluso algunas pueden no ser necesarias de trasladar por el hecho de usar CFG, por ejemplo.
Pero no todo es tan sencillo. Por varias razones:
  • Microsoft está desincentivando el uso de EMET en Windows 10, pero no se consigue cubrir exactamente el mismo espectro de protección. Sin embargo, sigue aconsejándolo en versiones anteriores.
  • Lo cierto es que casi todas las técnicas son eludibles con mayor o menor problema, especialmente las que Windows 10 se ha dejado para el final, con lo que quizás no se echen tanto de menos o no se gane demasiado.
  • Otras como EAF+ y HeapSpray sí le parecen buenas técnicas que se pueden echar de menos. De hecho, Microsoft se comprometía a estudiar cómo introducirlas en Windows 10 según vayan viendo.
  • Todo es muy cambiante, en cuestión de meses introducen y modifican funcionalidades, con lo que la propia documentación oficial puede resultar confusa. Otro consejo es que si queréis entender algo, no uséis Windows 10 en español, o tened uno en inglés cerca para comparar.
En las siguientes entradas, seguiremos ahondando en qué otras funcionalidades se han introducido en Windows 10 contra la ejecución de código.

Sergio de los Santos
Innovación y laboratorio
ssantos@11paths.com

No hay comentarios:

Publicar un comentario