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"
Sergio de los Santos
ssantos@11paths.com
