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

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
FilesMicrosoft SharedHelp 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.

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.

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

ssantos@11paths.com

@ssantosv