El último 0day de Internet Explorer (que son en realidad dos), trae novedades

lunes, 11 de noviembre de 2013



El viernes se alertó sobre una vulnerabilidad en Internet Explorer que permitía ejecutar código que estaba siendo aprovechada por atacantes. Al margen del peligro en sí del fallo, lo interesante de esta vulnerabilidad es la forma de ser explotada. Los atacantes han utilizado al menos dos técnicas nada convencionales, que los sitúan en una profesionalidad inusual. Veamos qué características definen el exploit.

El fallo ha sido descubierto por FireEye. Un 0day en productos de Microsoft es relativamente normal. De hecho, con este, son dos los que han sido encontrados en la última semana (particularmente prolífica en este aspecto). Al margen de la eterna discusión y las soluciones no adoptadas aún (con EMET, no hay peligro en ninguno de los dos casos), este 0day es muy especial no tanto por el fallo, sino por la forma de explotación. Una vez encontrada una vulnerabilidad, el atacante puede explotarla de varias formas. En este caso, han elegido un par de métodos muy interesantes, y nada habituales.

Cómo saber cómo infectar

Parte del código de Blaster
Lo habitual en las vulnerabilidades de ejecución remota de código, es que el atacante deba eludir un montón de trabas con las que el sistema operativo intenta detener la explotación. Lo primero y fundamental para el atacantes es situarse. Esto significa saber en qué sistema operativo se encuentra (y su versión) qué navegador (y su versión) y qué software adicional mantiene instalado (y sus versiones). Antiguamente, por ejemplo Blaster en 2003, probaba entre varias posibilidades. Apostaban por estar en un XP, XP SP1, 2000... con diferentes service packs. La posiblidad de infectar era "suerte" porque cada exploit tenía que ser diferente según el sistema operativo. 

Hoy, depende de la vulnerabilidad, el atacante encontrará que puede ser más o menos específico, y que la explotación tendrá éxito en más o menos ocasiones porque debe tener en cuenta DEP, ASLR, mayor presencia de navegadores diferentes, etc. El software adicional le puede servir habitualmente para encontrar zonas de memoria cargadas siempre en el mismo punto (y así eludir ASLR). En este aspecto juega un papel fundamental los plugins complementos de Internet Explorer (Java, Flash, librearías de Office...). Para conseguir esta información, habitualmente el atacante confía en el User-Agent, o pregunta directamente si existe un archivo o librearía cargada. A veces, simplemente lo intenta, sin comprobar nada.

Lo curioso de este ataque es que para situarse, pregunta directamente el timestamp de una DLL de sistema, esto es, cuándo fue creada y por tanto conocer así su versión. De hecho, se trata de otra vulnerabilidad adicional a la que permite la ejecución de código en sí. Es un problema de filtración de información por la que, con solo visitar una web, se puede conocer el timestamp de la cabecera PE de msvcrt.dll (y quizás de otros archivos). Este dato se envía al atacante y así decide qué técnica de exploiting usar. Para poder ejecutar código hoy en día en los Windows "modernos", necesita utilizar cadenas ROP para poder ir enlazando direcciones de memoria y conseguir "situarse" en la RAM con las instrucciones cargadas. El atacante, dependiendo de la versión de esta DLL, usará una u otra más adecuada que le permita tener éxito. En este ataque, solo se contemplaban las versiones en inglés del sistema operativo. Este fallo de filtrado de información afecta a Windows XP con IE 8 y Windows 7 con IE 9.

Infectando... sin escribir

Esto es aún más interesante. El payload, el código que después de superar todos los problemas para conseguir ejecutar algo, se ejecuta realmente... no se escribe en disco. Esto no es nada habitual. En marzo de 2012, Kaspersky alertó sobre algunas técnicas "fileless" de ciertos payloads y malware, pero no se volvió mucho sobre el asunto. Lo normal es escribir un fichero en código, y asegurarse la persistencia enganchándose a los puntos habituales del sistema operativo. Pero no es el caso. El payload queda cargado en memoria, volátil. El atacante corre el riesgo de que un simple reinicio elimine la infección, pero por otro lado esta técnica dificulta la detección por parte de usuarios o antivirus de forma drástica (en el caso de antivirus, queda fuera de juego). ¿Por qué actuar así? 

Teniendo en cuenta que FireEye ha descubierto el fallo en una página concreta que invita a pensar que se trata de un ataque del tipo "watering hole" (un página muy específica en Estados Unidos)... se puede pensar que los atacantes tenían claro que no necesitaban escribir a disco porque la víctima volvería todos los días a esa web, y así, en vez de situarse en el sistema esperando lanzarse en cada reinicio, confiaban en infectar a las víctimas con su visita diaria. El éxito estaba prácticamente garantizado tanto por los hábitos como por el hecho de que gracias precisamente a este técnica, la detección tardaría en llegar, y podrían pasar desapercibidos mucho tiempo. Por esta razón, se ha llamado "Operation Ephemeral Hydra"

Todos los detalles técnicos (las investigaciones aún están en desarrollo) se pueden encontrar en la página de FireEye.

Sergio de los Santos
ssantos@11paths.com

No hay comentarios:

Publicar un comentario