Stored XSS And SET

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:

Comment Form Vulnerable to XSS

 

In order to test it for XSS we will try to pass into the comment field the following script:

Alert Box – JavaScript Code

 

The result will be the following:

Comment Field Vulnerable to XSS

 

Now that we know where the vulnerability exists we can launch the social engineering toolkit.

SET – Menu

 

The attack that we are going to choose is the Java Applet Attack Method.

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.

SET Configurations

 

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.

SET – Encoders

 

Now we can go back to the web application and we can try to insert the malicious JavaScript code in the comment field that we already know from before that is vulnerable to XSS.

Malicious JavaScript Code

 

When a user will try to access the page that contains the malicious JavaScript the code will executed in his browser and a new window will come up that will contain the following message:

Fake message trying to convince the user to run the java applet

 

After a while the user will notice a pop-up box that it will ask him if he wants to run the Java applet.

Malicious Java Applet

 

If the user press on the Run button the malicious code will executed and it will return us a shell.

Remote Shell

 

Conclusion

As we saw stored XSS can be very dangerous as the JavaScript code executed once the unsuspected user has visited the vulnerable page.In this article the malicious attacker wanted to redirect the user to another page in order to run the malicious Java applet that lead to a shell.A potential attacker can use many tools with different arbitrary codes combined together in order to achieve his goal so regular penetration tests is a necessity for every company that wants to defend herself from non-ethical hackers.