An IE Same Origin Policy Bypass story

Hace un par de días estaba leyendo mis feeds cuando de repente un titular llamó mi atención: "Seria vulnerabilidad en Internet Explorer totalmente parcheado expone las credenciales de los usuarios". Una técnica de evasión para el same-origin-policy de Internet Explorer había visto la luz. Este tipo de vulnerabilidades son muy críticas, ya que SOP proporciona la separación entre los diferentes sitios web dentro de nuestros navegadores, y evita que una web maliciosa pueda acceder o modificar contenido de otra web legítima.

Le he estado pegando un vistazo a la vulnerabilidad en las últimas horas y vaya si funciona. La PoC publicada funciona perfectamente pero quizá no es la proximación más práctica (real) que un atacante tomaría. Por lo que sé, no se han publicado más detalles sobre la vulnerabilidad aparte de la propia PoC, así que vamos a pegarle un vistazo al PoC. He preparado mi propia prueba de concepto simplemente para ver si era capaz de explotarla de una forma más "maléfica".

A primera vista la vulnerabilidad parece una condición de carrera o similar. Tenemos dos iframes, el primero de ellos carga una página dinámica, por ejemplo 1.php. No se ha publicado el código de esta página, pero básicamente espera durante unos pocos segundos y luego redirige a la misma URL que carga el segundo iframe.

Ambos iframes cargan una página en el website victima. Es importante encontrar una página que puede ser cargada dentro de un iframe, porque si no la vulnerabilidad no se puede explotar. Proveedores como Google, Facebook, etc, normalmente configuran sus sitios con la cabeceza "X-Frame-Options" para evitar ataques de ClickJacking, lo cual podría ser un problema.

Sin embargo, con encontrar una sola página en todo el dominio que no tenga la cabecera "X-Frame-Options" es suficiente, y eso no es tan dificil como parece. Hay dos recursos bien conocidos que no están protegidos en la mayoría de los sitios web: robots.txt (el que usa el autor original) y favicon.ico (el que uso yo para un ataque un poco más práctico).

Hay una función llamada "go()" que hace la verdadera explotación. Es dificil de leer así que permitidme que lo decodifique para vosotros.

Aquí es donde está la chicha. Hay algunas llamadas a "alert" y "eval" que parecen ser importantes. No he podido averiguar por qué pero si las cambias no funcionan. Esta parte es la más compleja de la vulnerabilidad.

Carga el segundo iframe del que hablabamos antes en la variable "x". Entonces espera unos pocos segundos (1 segundo en el código mostrado) y muestra un mensaje. Como comentaba antes, este "alert" parece ser importante así que no lo podemos borrar, pero podemos elegir un mensaje que no haga advertir al usuario que algo malo está pasando. Después de eso, cuando el primer iframe ha cambiado del atacante al sitio victima (debido a 1.php) el código Javascript y HTML es inyectado en ese segundo iframe. No deberíamos ser capaces, porque es un dominio diferente, pero lo somos. Nos hemos saltado la same-origin-policy.

Vamos a ver como lo vería una víctima:

Algunos paises tienen leyes específicas sobre cookies y los sitios web tienen que mostrar un mensaje como éste. Muchos usuarios se han acosutmbrado a ellos y simplemente pulsan aceptar.

Cuando injecté código en el iframe, utilicé un botón de google, de estos que se usan para autenticarte en sitios externos. Puede que no sea el blog más bonito del mundo, pero... parece un blog de verdad :)

Se abre la pantalla de autenticación de Google. Todo parece correcto pero el javascript debería haber cambiado al "action" del formulario de login, con lo que las credenciales deberían ir a un dominio diferente.

¡Hecho! Una vulnerabilidad realmente interesante. No puedo esperar a que salgan más detalles de la vulnerabilidad y ver porque los "alert", "eval" y "setTimeout" son tan importantes.