Un kit de exploits de masas que puede eludir EMET: ¿hora de preocuparse?
EMET de Microsoft es una herramienta que actúa en una de las fases críticas del aprovechamiento de vulnerabilidades que habitualmente acaban en infección con malware: las técnicas de explotación y salto de medidas de seguridad. Es una solución más eficaz porque en esta etapa del ataque, las posibilidades de un atacante están limitadas, mientras que el abanico a la hora de aprovechar vulnerabilidades nuevas o viejas o de hacer que el malware pase desapercibido, es de un ancho infinito y cualquier defensa juega en desventaja. Sin embargo, las técnicas de exploiting son relativamente pocas y conocidas. EMET juega con el concepto de intentar detectar que se está haciendo uso de estas técnicas (unas decenas) y evitar que el exploit llegue a lanzar el payload. De ahí que sea una herramienta fundamental, que no depende de firmas, parches, actualizaciones… muy rara vez aparecen nuevas fórmulas de exploiting para lanzar payloads, y solo de vez en cuando métodos para eludir todo EMET en sí mismo. No estamos ante ninguno de los dos casos, puesto que las técnicas ya son conocidas, es solo que no es habitual verlas «ahí fuera».
Veamos los detalles técnicos.
 |
| Configuración de EMET |
Angler elude DEP
Lo que ha detectado FireEye es que Angler está eludiendo DEP. Eso se hace desde siempre porque DEP viene activo por defecto en el sistema y lo aprovechan los programas que suelen ser explotados. Desde el punto de vista del atacante, desactivar DEP consiste fundamentalmente en llamar a VirtualProtect y VirtualAlloc marcando la página como de ejecución. Pero para hacerlo, normalmente se utilizan técnicas muy maduras y eficaces de ROP. Sin embargo, Angler innova. Llama directamente a las rutinas dentro de Flash.ocx y Coreclr.dll (de SilverLight). Eluden DEP y la detección de técnicas ROP que heurísticamente intenta detectar EMET, simplemente porque no las usa. Lo cierto es que esto es interesante, pero no «preocupante». DEP no es lo más difícil de eludir para un atacante. ASLR suele ser más complicado. EMET todavía tendría la capacidad de «cazarlo».
¿Pero dónde está VirtualProtect? EAF y EAF+
Para eludir 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 de 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. Pero existe un truco: acceder a la Import Table de una librería que se importe en cada proceso. Y ese es el caso de user32.dll, que es el caso que utiliza Angler. Es importante destacar que esto ya se conocía como método para eludir EMET, y como método general de exploiting desde hace años. Es más, el propio Microsoft avisa en general de que EAF es un método de protección «débil» por sí mismo. Angler usa este truco en un exploit de Silverlight, no protegido por EAF+. Pero con Flash es diferente, porque queda protegido por EAF y EAF+. EAF+ es exactamente lo mismo que EAF pero con una lista negra de librerías predefinida y solo en Internet Explorer (aunque todo es configurable). Flash.ocx está 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 no estar en la lista negra… u otra técnica. Así que usa igualmente la Import Table de Flash.ocx (del que ya conoce la base) y, a partir de kernel32.dll, localiza VirtualAlloc y otras APIs para el resto del ataque, eludiendo EAF+.
 |
| Configuración de EAF+ en EMET, la lista negra de dlls a las que no se le puede sacar la tabla de exportación |
Luego lanza el código de TeslaCrypt en este caso, y si utiliza infección «Fileless» (que evita almacenar nada en disco) se las ingenia para crear un proceso fuera del radar de EMET.
Conclusiones
En resumen, esto se trata de un excelente trabajo en exploiting con técnicas interesantes. Los matices y reflexiones que podemos extraer son varios. El hecho de que técnicas de exploiting muy avanzadas lleguen a un exploit kit de masas sí es preocupante, no el hecho de eludir EMET en sí mismo. EMET tiene sus limitaciones, aunque sea una herramienta más eficaz por definición (sus «enemigos» son menos) ha sufrido varios problemas de implementación y aplicación de técnicas fallidas que ya han sido descubiertas. Algunos problemas han sido subsanados y otros por definición, nunca podrán serlo. Además, a efectos prácticos y aunque no hay datos, parece que EMET no es una herramienta popular entre el usuario medio, así que el hecho de que se eluda en este kit, quizás no haga que con Angler se ganen muchas más víctimas.
Así que surge la duda: ¿por qué molestarse en eludir una barrera tan poco popular? Intentemos ver más allá. Hace poco Microsoft sugería (de forma un tanto controvertida) que muchas de las características de EMET ya venían incluidas en Windows 10, y que EMET no era necesario. Lo cierto es que es tan necesario que lo que está ocurriendo poco a poco es que el sistema operativo, de serie, incluye funcionalidades que se han ideado en un primero momento para EMET, y que está sirviendo como campo de pruebas.
Por tanto, lo que realmente puede revelar este descubrimiento es que los atacantes de masas están dando el siguiente paso. Igual que cuando apareció DEP activo por defecto en Windows XP en el verano de 2004 con el Service Pack 2, o como cuando en 2006 Windows Vista introdujo ASLR en el mundo Windows… Los atacantes tuvieron que comenzar a pelar contra nuevas barreras que ya venían «de serie» porque comenzaba a complicarse las técnicas pero tenían que seguir garantizando los niveles de infección. Algunos afirmaron que se les acabó el chollo, y que tendrían muy difícil la explotación… Pero los atacantes lo consiguieron y «normalizaron» el eludir DEP o ASRL en sus exploits. Así que a partir de de Windows 10 o su sucesor, quizás las mejoras contra el aprovechamiento de exploits de serie irán mejorando, pareciéndose probablemente a lo que hoy es EMET. Y esto pueden ser los primeros pasos que allanen el camino a los exploits kits del futuro contra lo que venga tras Windows 10. En concreto, contra Edge, que sí que mejora sustancialmente a Internet Explorer. Por último, solo recordar que esto se ha probado en Windows 7, con exploits para Flash y Silverlight, ambos bajo Internet Explorer de 32 bits. Windows 7 ya lleva un Internet Explorer desactualizado por definición porque se ha descontinuado, por tanto, su usuario tiene muchos otros problemas de los que preocuparse (entre otros, la amplia gama de vulnerabilidades que puede aprovechar el atacante para intentar lanzar esos exploits). Y por supuesto, recordad siempre que EMET no es perfecto, ni nada lo será nunca, pero es una herramienta imprescindible.
Fuente: http://blog.elevenpaths.com/2016/06/un-kit-de-exploits-de-masas-que-puede.html?m=1
