Una alternativa para combatir el último 0day en Internet Explorer

martes, 24 de septiembre de 2013

Hace unos días se descubrió un verdadero 0day en Internet Explorer (CVE-2013-3893). "Verdadero" porque se trata de una vulnerabilidad encontrada mientras está siendo aprovechada por atacantes desde no se sabe cuándo, no porque haya sido descubierta por un investigador y hecha pública sin más (aunque se le llame así, eso no es un 0day). Se han ofrecido ya varios remedios para mitigarla mientras aparece un parche. Aun así, a modo divulgativo hablaremos de por qué funciona, y métodos alternativos para paliar esta y otras vulnerabilidades.


El fallo es un problema de acceso por Internet Explorer a objetos en memoria que han sido eliminados o incorrectamente asignados por el motor de representación HTML (mshtml.dll). Podría permitir la ejecución de código. Según FireEye, se ha usado esta vulnerabilidad para atacar varias organizaciones concretas japonesas, en una operación que se ha dado en llamar "DeputyDog". Tirando del hilo de algunos dominios, emails y servidores, se cree que podrían ser los mismos que comprometieron los certificados de Bit9 a principios de año.

El exploit se construye exclusivamente a través de JavaScript y se vale de una librería que se debe cargar previamente también a través de JavaScript. Con este lenguaje trastocaba la memoria libre del heap, espera a que un objeto llamara a ese objeto liberado y tomaba el control de EIP.

Soluciones y "culpables"

Microsoft publicó rápidamente un FixIt. Se trata de un pequeño programa específico para solucionar la vulnerabilidad mientras se prepara un parche de verdad. En realidad consiste en la instalación de un SHIM, un trozo de código que intercepta y modifica el comportamiento de las APIs.

Aplicar el FixIt es una de las soluciones que se pueden adoptar por ahora, entre otras. Bloquear el tráfico que se sabe que genera, afinar el antivirus... pero como todas las soluciones reactivas, quizás se apliquen demasiado tarde. Aunque se dio a conocer el 17 de septiembre, FireEye conoce que el fallo se estaba explotando desde al menos el 19 de agosto.

Las soluciones preventivas son mucho más interesantes. EMET hubiera impedido la ejecución del código; una correcta implementación de los permisos (el exploit escribía una DLL en %APPDATA%, algo que ningún programa legítimo suele hacer); e incluso la elevación de la seguridad en las zonas de Internet Explorer podrían haber impedido la explotación.

Pero en este caso concreto llama la atención el uso de una DLL de sistema que no tenía activado ASLR. ASLR permite dificultar que un fallo de seguridad sea aprovechado por los atacantes. El problema es que, basta con que el proceso vulnerable cargue una sola DLL sin esta protección, para que toda la seguridad se venga abajo y el atacante encuentre un "punto de apoyo" que le facilite el trabajo. En este caso la culpable era la DLL hxds.dll  ("Microsoft Help Data Services Module") alojada en "C:\Program Files (x86)\Common Files\Microsoft Shared\Help\ hxds.dll". 

Los ejecutables (ya sea en forma de DLL o EXE) indican en su cabecera si quieren someterse al ASLR del sistema, y que este los coloque o no en posiciones aleatorias cuando se cargan. Se trata de un valor en su cabecera que lee Windows y con el que actúa en consecuencia. En concreto, hablamos de de DllCharacteristics dentro de la estructura PE IMAGE_OPTIONAL_HEADER. Según la documentación de Microsoft, para que un programa sea cargado con una base aleatoria el valor IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE debe ser 0x0040. Si analizamos la DLL en cuestión con CFF Explorer, se puede observar claramente que este valor no está activado.

ASLR desactivado en la cabecera de hxds.dll
Así, la DLL carga siempre en la misma posición de memoria y el atacante sabe dónde acudir. La dirección base también está presente en la cabecera PE. En la imagen anterior también se observa ImageBase establecido a 0x51BD000. Y en esa dirección de su propia memoria reservada (virtual, no confundir con el swap que Windows traduce erróneamente como "memoria virtual") se establecerá siempre la DLL y a partir de ahí, las funciones que exporte.

Si se modifica sin embargo el valor de DLLCharacteristics, se modifica su comportamiento. Windows la carga en una dirección diferente cada vez. Para comprobarlo se puede usar Process Explorer y ejecutar Internet Explorer accediendo a "ms-help://" para cargar la librería. Sin el valor en la cabecera de la DLL establecido a 0x0040, Internet Explorer cargará hxds.dll en la misma dirección. Con el bit, en diferente. La buena noticia es que se puede activar "a mano". En la imagen siguiente, se a modificado a mano el valor de la cabecera, activando el ASLR.

Con el ASLR activo, la DLL se carga en otra dirección diferente a 0x51BD000. En el ejemplo 0x61E40000
Si a Microsoft no se le hubiera olvidado este detalle al compilar la DLL (añadiendo /DYNAMICBASE como opción), el fallo hubiese sido más complejo de explotar (o habrían acudido a otra DLL, quién sabe... hay más que no utilizan ASRL). No hemos realizado pruebas exhaustivas, y quizás en algún momento la DLL puede funcionar erráticamente con ASRL activado. Pero, dado el caso, solucionar fallos de compatibilidad es problema y responsabilidad de Microsoft, que, a estas alturas, debería haberla programado para funcionar bien con esta medida de seguridad activa.

Sergio de los Santos

No hay comentarios:

Publicar un comentario en la entrada