El día que Microsoft cerró muchas puertas... pero abrió un ventanal

lunes, 29 de junio de 2015

El problema presentado en la REcon de mediados de junio, es grave. Y la respuesta de Microsoft, más aún. Lo descubierto por Brian Gorenc, AbdulAziz Hariri, y Simon Zuckerbraun, a efectos prácticos, invalida el ASLR de Windows de 32 bits.

Brian Gorenc, AbdulAziz Hariri y Simon Zuckerbraun no son unos desconocidos en el exploiting. Trabajan para la Zero Day Initiative, de HP. En febrero ya se ganaron 125.000 dólares (que donaron) por sus investigaciones sobre la Isolated Heap y la función de MemoryProtection. En ese momento no dieron detalles, pero desde entonces han pasado ya 120 días y no todo se ha arreglado, así que han publicado un documento con todos los detalles.

¿Qué es MemoryProtection y la Isolated Heap?

Microsoft a veces publica no solo parches, sino que (sin decir nada) en ocasiones introduce mejoras en los boletines. El pasado verano, los boletines MS14-035 y MS14-037 vinieron con dos nuevos sistemas de mitigación de explotación para Internet Explorer. Uno contemplaba la creación de un heap separado para procesar el DOM de las páginas. Esto dificulta mucho la explotación (que se termine ejecutando código) de las vulnerabilidades. El otro introducía MemoryProtection. Se trata de una mejora a la hora de liberar la memoria del heap, que pretendía reducir el riesgo de que las vulnerabilidades provocadas por "use after free" de punteros puedan ser explotadas más fácilmente. Y así fue. Se redujeron el número de fallos explotables por estas causas. Gracias a estas dos estrategias, se cerraron muchas puertas (posibilidades de que muchos tipos de vulnerabilidades pasadas y futuras basadas en el mismo fallo fueran explotables).

Nada es inviolable y, a pesar de estos sistemas de mitigación, en febrero de 2015, en FireEye ya detectaron exploits "in the wild" que conseguían eludir estas mitigaciones. Incluso los propios Gorenc, AbdulAziz Hariri y Simon Zuckerbraun han mostrado cómo conseguirlo con todo lujo de detalles en este mismo estudio. Google llegó a una conclusión parecida a principios de enero... . Pero eso no es lo más importante. Bien por Microsoft y sus estrategias para mejorar la seguridad en Internet Explorer desde la raíz... o no.

Se abrió el ventanal

El problema es que los investigadores no solo han conseguido eludirlas sino que, ayudándose de la implementación de estas mitigaciones, pueden eludir ASLR en Windows de 32 bits. Ciertas funcionalidades de estas mitigaciones les permiten deducir las direcciones base en memoria de ciertas DLL, con lo que, a efectos prácticos, permite a un exploit eludir ASLR puesto que solo necesitará conocer estas direcciones para situarse y lanzar de forma cómoda su shellcode o exploit correspondiente. Aquí un vídeo que lo muestra. En resumen, han abierto un ventanal... y no piensan cerrarlo. Pero ojo, esto solo ocurre de forma fiable en las versiones de 32 bits de Internet Explorer 10 y posteriores.

Y esta ha sido la "excusa" para no arreglarlo. Microsoft ha respondido que las versiones de 64 bits se benefician más y mejor del ASLR (más combinaciones posibles) y que por tanto, los usuarios de sistemas de 32 bits, no tienen tanta protección. Esto es obvio, pero no por ello hay que deducir que, si su protección es menor, ¿qué más da que sea eludible del todo? Error.

Parece que Microsoft antepone el interés de reducir un subconjunto de tipos de vulnerabilidades UAF, al de una protección tan importante (y más genérica) como es el ASLR. En cierto modo tiene sentido: no quieren invertir recursos en arquitecturas obsoletas, necesitan deshacerse de la tecnología de 32 bits en cuanto les sea posible. Y este tipo de problemas, les "ayuda".

¿Es grave o no? ¿Me afecta?

Los atacantes ya saben eludir ASLR en Internet Explorer. Lo suelen hacer a través de plugins instalados u otras técnicas más o menos elaboradas. Por tanto, esto es otra herramienta más en su kit de explotación. Por otro lado, solo afecta a las versiones de 32 bits del sistema operativo Windows 7 y 8, que es donde se lanza el Internet Explorer de 32 bits nativo. De estos quedan pocos, aunque los hay. Hay estudios de 2012 que hablan de que solo el 10% de los Windows son Windows 7 de 32 bits. Ante esto, si no se cambia de arquitectura, solo queda dejar de usar Internet Explorer o configurarlo con EMET.

Pero ojo, no está de más recordar algo interesante sobre Internet Explorer y reforzarlo en este aspecto. Curiosamente, Internet Explorer 10 funciona en Windows de 64 bits como proceso de 64 bits... pero también como procesos de 32 bits (sus pestañas). Esto no hace que sea vulnerable al fallo descubierto por la gente de HP, pero no está de más recordarlo y subir su seguridad (si se puede).

IE 10 sobre Windows 8 de 64 bits por defecto. Proceso padre con nivel de integridad medio y 64 bits.
Pestaña con nivel de integridad bajo y 32 bits.


64 vs 32 bits

En Windows de 64 bits, hay dos Internet Explorer instalados. Uno en "Program files" y otro en "Program Files (x86)". El primero es Internet Explorer nativo en 64 bits, y el segundo en 32 bits. Aunque se lance el de 32, el sistema operativo lo sustituirá rápidamente por el de 64 (aunque mantiene las pestañas de 32). Este es más seguro por varias razones:
  • IE de 32 bits solo puede correr plugins y ActiveX que sean de 32 bits. Los creadores de malware quieren acaparar al mayor número de víctimas, y por tanto programan en 32 bits porque es cómodo, y compatible con lo antiguo y lo moderno.
  • Los exploits para IE de 64 bits son más complejos de crear.
  • Las mitigaciones contra la creación de exploits en un entorno de 32 bits son más sencillas de eludir en 32 bits (y esto es justo lo que ha ocurrido). Pero esto no se le suele decir al usuario. Estéticamente, son idénticos. Hasta Internet Explorer 10, si se abre el navegador de 32 bits, todo es 32 bits, y si se abre el de 64, todo es 64 bits. Pero a partir de Internet Explorer 10, la cosa cambia. En esta versión, el proceso "broker" que corre en el modo de integridad medio, es siempre un proceso de 64 bits, y los hijos (las pestañas), de 32. Así se consigue compatibilidad con los plugins. 
Además, al hecho de que Internet Explorer se ejecute en un nivel de integridad bajo, Microsoft lo llamó "Modo protegido". Esto está relacionado con los niveles de integridad con los que se ejecuta el navegador y sus pestañas (el proceso padre en modo normal, y las pestañas hijas normalmente en modo bajo).

El modo protegido (activo por defecto) es lo que hace que los hijos se ejecuten
en modo de integridad bajo (y no medio), lo que los aísla

Para complicar el asunto, en Windows 8 existen dos versiones del navegador: la de "Escritorio" y la de "Interfaz moderna", esa que nadie usa pensada para los móviles y tabletas. En la interfaz moderna, todo es 64 bits y en el escritorio no. Y esto se complica aún más con Internet Explorer 11 dependiendo si se está en Windows 7, 8 u 8.1...

Protección

Visto este problema que permite eludir el ASLR en 32 bits, ¿es buena idea que todo Internet Explorer (y no solo su proceso padre) se ejecute en 64 bits? Sí. El problema podría venir por la compatibilidad de los plugins, pero es cuestión de elegir bien durante su instalación.

Por tanto, en un Windows 64 bits de escritorio, ¿se puede obligar a que incluso las pestañas sean procesos de 64 bits? Sí. Esto se ha llamado "Modo protegido mejorado". Si el "modo protegido" está relacionado con los niveles de integridad, el "mejorado" tiene que ver además con la arquitectura. Eso sí, insistimos en que antes de habilitarlo, es necesario estar seguro de que las extensiones o plugins que se usan en el navegador son compatibles. Se puede habilitar el "Modo protegido mejorado" desde las opciones avanzadas del navegador.
Activar modo protegido mejorado (solo Windows 8)
En Internet Explorer 10, activando esa opción, conseguiremos este efecto:

Pestañas de 64 bits, preo además.. en un AppContainer

Un AppContainer es un nivel de "sandbox" (nivel obligatorio, como lo llama Process Explorer, o de integridad) pensado para las apps del market de Windows (a partir del 8), bastante restrictivo. Para rematar el lío, en Internet Explorer 11 hay que dar un paso extra. Existe además otra opción avanzada de seguridad que dice "Habilitar procesos de 64 bits para el modo protegido de Internet Explorer" Si eso no está activo en IE11, aunque el modo protegido mejorado esté activo, las pestañas seguirán siendo de de 32 bits (aunque dentro de un AppContainer). ¿Complejo? Sí.

Algunas páginas no funcionarán con el modo protegido mejorado. La buena noticia es que podrás deshabilitarlo selectivamente por dominios tocando una rama del registro (TabProcConfig).

Sergio de los Santos
ssantos@11paths.com