Anatomía de un exploit – dentro de la CVE-2013-3893 Internet Explorer día cero – Parte 1

Como usted probablemente sabe, de Microsoft Patch Tuesday 10 2013 incluye una actualización para Internet Explorer que se cierra no menos de diez RCE, o agujeros ejecución remota de código.

Este tipo de vulnerabilidad significa que sólo mirar una página web con trampa que puede infectar con malware, incluso si usted no hace clic en cualquier cosa en la página.

Por desgracia, un exploit que se aprovecha de uno los diez agujeros, CVE-2013-3893, es conocido por ser en la naturaleza.

Los cibercriminales han estado utilizando, una página HTML de prueba de concepto se ha publicado que se puede ajustar para sus propios ataques, y el popular herramienta de penetración Metasploit ahora lo incluye.

Así que en lugar de dejar que aplique el parche y acabar de una vez, pensamos que sería mejor mirar esta hazaña con cierto detalle.

Esperamos que esto le ayudará a entender las longitudes que los cibercriminales se irá a fin de atacar a su equipo, a pesar de los niveles de protección que las versiones modernas de Windows e Internet Explorer incluyen.

No se preocupe si usted no es técnico: hemos tratado de mantener el código ensamblador y la jerga de programación al mínimo.

Simplemente deslice sobre cualquier cosa que no entienda y obtener una idea de cómo piensan cyberattackers – "Conoce a tu enemigo" es una parte útil de cualquier defensa.

Y, no, no hemos regalado tanto que se puede convertir este artículo en un ataque de su propio: se trata de una guía explicativa, no es un tutorial de cómo hacerlo.

El núcleo del agujero

Los atacantes se aprovechan de un error en la funcionalidad de la captura del mouse de Internet Explorer.

En JavaScript, un objeto en una página web en Internet Explorer puede tomar o ceder el control de los eventos de ratón que ocurren en la ventana Brower, como hacer clic y doble clic.

Esto se hace usando las funciones SetCapture () y ReleaseCapture ().

Un objeto también puede declarar una función onclosecapture, que se llamará automáticamente si alguna vez pierde el control del ratón, por ejemplo debido a que otro objeto llama SetCapture () para tomar el relevo.

Nuestros atacantes parecen haber descubierto que estas funciones se pueden utilizar para engañar a Internet Explorer, por orquestar una secuencia inusual de operaciones, algo como esto:

  • [1] 10000 artículos en la página Web actual, dando a cada uno una cadena título de "3333 …. 3333".
  • [2] Liberar la memoria de los últimos 5.000 artículos estableciendo el título de nuevo a una cadena en blanco.
  • [3] Crear dos elementos más, por lo que uno de los padres de la otra.
  • [4] Marcar onclosecapture acontecimientos para el elemento secundario, en el que más de 10.000 artículos titulados "3333 …. 3333" se creará.
  • [5] setCapture Call () del elemento secundario.
  • [6] Call setCapture () de la matriz (que provoca la onclosecapture en [4] para ser llamado en el elemento secundario).

¿Qué hace?

Esto es lo que se ve si se ejecuta el código de activación que hace esto bajo un depurador, el uso de Windows 7 con Internet Explorer 9:

Si usted no está familiarizado con los depuradores, esta ventana le indica que el programa se ha estrellado en la dirección 0x6AA33859 en el MSHTML.DLL biblioteca del sistema, tratando de ejecutar la instrucción:

MOV EDX, DS: [ECX]

(En Intel Assember notación, los datos fluyen de derecha a izquierda, por lo que esto significa "mover el valor de [ECX] en el registro EDX." Y los corchetes significa "capturar el valor en la dirección de memoria almacenada en ECX, no el valor de sí mismo ECX "El DS:. sólo denota que el valor proviene de segmento de datos del procesador).

Para explicar con más detalle, el código en y después de la instrucción ofender arriba hace lo siguiente:

MOV EDX, [ECX]; Fetch el contenido del 
                  , La dirección de memoria en ECX,
                  ; Donde se controla ECX
                  ; Por la cadena en [1] y [4]
                  , En la página web del atacante.
MOV EAX, [EDX + C4]; Fetch el contenido del 
                  , Dirección C4 bytes allá de eso.
LLAME EAX, y llamarlo como una subrutina.

La excepción se produce porque ECX = 0x33333333 (el código ASCII para la cadena de texto "3333"), pero no hay ninguna memoria asignada en esa dirección por el procesador para leer.

Parece como si la memoria que fue liberado en [2] se volvió a utilizado por Internet Explorer para almacenar datos que controlan el flujo de ejecución en MSHTML.DLL (motor de renderizado de Microsoft), y luego volver a utilizar erróneamente en contra para salvar el cadenas de texto creadas en [4].

Ese es un uso libre de errores después, y en este caso, significa que nuestros atacantes pueden llevar Internet Explorer mal camino: se puede engañar al navegador en el uso de datos no confiables desde su página web remotos a decirle a su equipo en saltar al lado de la memoria.

Eso significa que es muy probable que sea una oportunidad para que ICE, o la ejecución remota de código.

El paso siguiente

Para seguir avanzando, los atacantes tenían que forzar ECX para contener la dirección de memoria que se asigna, y que pueden influir.

Adición de un paso [4,5] a la lista anterior hace el truco:

  • [4,5] Crear 320 cadenas de texto que ocupan 1 MB cada uno, que contiene los bytes 0x12121212 repite una y otra vez.

Esto se conoce como un aerosol montón, y es una operación que usa potentes funciones de control de cadenas de JavaScript para forzar el sistema operativo para asignar grandes bloques de memoria en una forma controlada.

Si ejecutamos de nuevo Internet Explorer hasta que se estrella, y luego mirar a los bloques de memoria asignados por Windows, podemos ver el resultado de la aspersión montón.

La columna de tamaño de muestra que estos bloques son 0x00100000 bytes de longitud, o 1MB:

Cada uno de estos bloques está repleta de los bytes 0x1212 …. 1212.

Nótese en particular – y pronto veremos por qué esto es terriblemente conveniente – que el bloque de memoria que contiene la dirección 0x12121212 (y la dirección de 0x121212D6, que es 0xC4 bytes más adelante), es uno de los trozos llenos de 0x1212 …. 1212.

Encontrar el tamaño adecuado para cada objeto aerosol montón, y el número adecuado de asignaciones de memoria para llevar a cabo con el fin de obtener un resultado limpio y explotable, no necesita hacer analíticamente.

Los cibercriminales pueden ahorrar tiempo y esfuerzo, simplemente usando ensayo y error – un proceso que puede ser automatizado.

Así, en lugar de utilizar la cadena de texto "3333", que en los pasos [1] y [4] anterior, nuestros atacantes pueden elegir un valor que corresponde a una dirección dentro de uno de los bloques que conocen su aerosol montón producirá.

En el exploit publicado, eligieron 0x12121202, aunque muchos otros lo habrían hecho igual de bien, por lo que los pasos [1] y [4] ya no han ECX en "3333".

En su lugar, se convierte en ECX 0x12121202, y los ladrones conseguir esto:

; EDX obtiene el contenido del 12121202

MOV EDX, [12121202]

; EDX es ahora 12121212, por lo
; EAX obtiene el contenido de EDX + C4 (121212D6)

MOV EAX, [12121212 + C4] 

; EAX está 12121212, que llamamos 

LLAME 12121212

, La ejecución se encuentra ahora en una dirección se controla!

En las versiones de Windows XP SP3 antes, los atacantes ya habrían ganado la batalla en este punto, mediante la adaptación de las cadenas de texto entre [4,5] para que contenían shellcode (código ejecutable oculto en fragmentos de datos) a partir de 0x12121212, tanto inmediatamente conseguir controlar.

Pero en estos días (y estamos en Windows 7 en este artículo, recuerda), bloques de memoria repartió por el sistema operativo – asignaciones "en el montón", como se les conoce – se fija para ser NX, o no ejecutar, por predeterminado.

Si intenta ejecutar una instrucción en una página de memoria marcada NX, los pasos de procesamiento en y se detiene.

Esta es la base de la DEP, o Prevención de ejecución de datos, y eso significa que a pesar de que nuestros atacantes pueden controlar exactamente lo que está en la dirección 0x12121212, y desviar el procesador a la misma, no pueden hacer que se ejecute:

En Windows XP, los atacantes DEP ralentiza un poco, pero no mucho: todo lo que tiene que hacer es ajustar el spray montón para que el valor en 0x121212D6 es una dirección en la memoria ejecutable.

(0x121212D6, recuerde, es 0x12121212 +0 xc4: ahí es donde la CPU saltará como un efecto secundario de provocar este error, debido a la instrucción CALL EAX se muestra arriba.)

Las fuentes más ricas de alimentos listos para el uso de memoria ejecutable son los numerosos archivos DLL del sistema que casi siempre son cargados, como Kernel32.dll, User32.dll y Gdi32.dll.

Moverse por ASLR

En Windows 7, sin embargo, recoger direcciones de archivos DLL en el sistema es mucho más difícil de lo que parece, a causa de ASLR, o el diseño del espacio de direcciones al azar.

Por ejemplo, aquí hay una tabla de nuestro equipo de prueba, que muestra dónde se supone que Internet Explorer y sus primeros archivos DLL para cargar, y donde se carguen en tres reinicios sucesivos:

En resumen:

  • DEP detenga atacantes con una vulnerabilidad como éste de saltar directamente a su shellcode tan pronto como el exploit toma el control.
  • ASLR detiene atacantes eludir DEP saltando en una DLL del sistema, ya que no saben a dónde va a estar en la memoria.

→ En Windows XP, el sistema de carga de archivos DLL en el mismo lugar todo el tiempo, en todos los equipos, por lo que XP mucho más fácil de hackear. Eso por sí solo es suficiente razón para deshacerse XP tan pronto como sea posible, independientemente de la inminente "no más parches" fecha límite de abril de 2014.

Pero nuestros atacantes tienen una forma de evitar esto, debido a que algunos archivos DLL común y popular todavía se anuncian como incompatible con ASLR, y por lo tanto se cargan sin ella.

Así, añadieron esta línea de JavaScript para atacar a usuarios de Windows 7:

try {location.href = 'ms-help :/ /'} catch (e) {}

Si usted tiene Office 2007 u Office 2010 instalado, tratando de abrir una ms-help :/ / URL hace que Internet Explorer cargue la biblioteca de compatibilidad hxds.dll:

Lamentablemente, la dirección 0x51BD0000 es exactamente donde se supone que se carga, ya que ha sido elaborado por Microsoft sin la opción de llamada DYNAMICBASE, lo que provoca que se quede al margen de ASLR:

Es cierto que esto restringe los atacantes para infectar ordenadores en los que se instala Office – pero en la práctica, que no es es importante limitación: incluso si usted no es dueño de la oficina, es muy posible que tenga una versión de prueba sobrante de cuando compró su PC.

En este punto, los atacantes están a punto de controlar el equipo, después de haber evadido todo lo siguiente:

  • La gestión de memoria de Windows.
  • "Sandbox" de JavaScript.
  • Prevención de ejecución de datos.
  • Dirección Asignación aleatoria del diseño del espacio.

La buena noticia es que todavía tienen una buena cantidad de trabajo por hacer.

Antes de que puedan ir más lejos, por ejemplo, tienen que elegir qué dirección hxds.dll van a escribir en el desplazamiento 0x121212d6, al ser el objetivo de la fatídica LLAMADA EAX que les dará su primera instrucción de código máquina ejecutado ilegalmente.

La mala noticia, por supuesto, es que ya sabemos que nuestros ladrones van a tener éxito al final.

Así que, por favor, únase a nosotros la próxima semana para la segunda parte, donde le mostraremos lo que van a hacer, y por qué, y cómo se puede detectar y prevenir sus nefastas actividades.

NB. Sophos Anti-Virus en todas las plataformas detecta y bloquea esta hazaña como Exp/20133892-B.

Imagen de Shattered Glass cortesía de Shutterstock .