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
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”:
The page loads when you enter a URL like the one below:
http://some.site/page.html?default=Spanish
We can perform a DOM Based XSS attack by making the victim click on the following link:
http://www.some.site/page.html?default=<script>alert(document.cookie)</script>
The browser creates a DOM object for the page, where in document.location it contains the payload javascript. As it does not expect to find HTML tags, the browser pastes it into the page and then executes it, also executing the payload, and we would get the victim’s cookie.
¿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.