Stored XSS is the most dangerous type of cross site scripting due to the fact that the user can be exploited just by visiting the web page where the vulnerability occurs.Also if that user happens to be the administrator of the website then this can lead to compromise the web application which is one of the reasons that the risk is higher than a reflected XSS.
In real world scenarios once a stored XSS vulnerability have discovered,the penetration tester reports the issue and provides a brief explanation in the final report about the potential risks but he doesn’t continue the attack as it is not necessary except if the client asks it.However a malicious attacker will not stop there and he will try to attack the users by combining tools and methods.So in this article we will examine how an attacker can use SET with a stored XSS in order to obtain shells from users.
First of all stored XSS can be discovered in web applications that are allowing the users to store information like comments,message boards,page profiles,shopping carts etc.Let’s say that we have a web application with the following form:
In order to test it for XSS we will try to pass into the comment field the following script:
The result will be the following:
Now that we know where the vulnerability exists we can launch the social engineering toolkit.
The attack that we are going to choose is the Java Applet Attack Method.
We will enter our IP address in order the reverse shell to connect back to us and we will choose the first option which is Java Required.
Next we will have to choose our payload and our encoder.In this case we will select to use as a payload a simple Meterpreter Reverse TCP and as a encoder the famous shikata_ga_nai.
After a while the user will notice a pop-up box that it will ask him if he wants to run the Java applet.
If the user press on the Run button the malicious code will executed and it will return us a shell.