Detecting cross site scripting

XSS – me

Acunetix xss scanner

I’ve included the link to the Acunetix add-on from my site. You have to sign up with Acunetix in order to receive the add-on and even then it comes bundled with an executable. If for some reason my link doesn’t work with your version of firefox then simply go to the Acunetix site and download their latest version.

Detecting sql injection

SQL inject me

Developer tools are always handy to have because if you can build it you can break it. The web developer add-on will allow you to easily see hidden form fields, javascript, cookies, etc. Firebug will allow you to easily see how the application is built by simply mouseing over the layout. Firebug is also a debugger and will allow you to set breakpoints for javascript, both are a must have.

Firebug

Web developer

Modification tools, if you want to modify a request before it’s sent to the server tamper data is a great tool inside the browser for the job. User agent switcher will allow you to pretend to be any browser you’d like, don’t forget the starbucks iphone problem. Add n edit cookies is another modification tool that will allow you to easily change cookies so that you can impersonate a cookie you have obtained.

Tamper data

User agent switcher

Add n edit cookies

Miscellaneous add-ons. Show IP is a great add-on that will show you the IP connecting to, this may seem lame at first but when you are assessing multiple environments or malware this is always handy. Leet key is another great tool inside the browser that will perform encoding (base64, URL, rot13, etc) and even generate hashes.

Show IP

Leet key

Notable mentions

Foxy proxy

Noscript

If you have any other recommendations please let me know.

Most web site worms spread because they allow javascript to be inserted somewhere into the web application. For example in twitter when a status is updated (via a moronic “tweet”) you are allowed to insert words, sentences, and even links to other interesting sites. If twitter allows you to input all this information what do they block? Javascript is a well known programming language that you should never allow to be inserted into your web application. Even though many web developers know this they continually make mistakes and allow javascript to be inserted into their web apps. There are different categories of javascript attacks such as XSS and XSRF, I’m not a big fan of this naming convention but  you should be familiar with the terms and what they mean. Most all web app worms are spread via the XSRF attack. Basically a XSRF attack is where javascript (possibly other languages) is inserted into the web app, that javascript will then make a request on behalf of the user. This request could be malicious in nature or in case of the twitter worm examples just for fun. The example I’ll be going over will be a classic XSRF attack where I’ll insert javascript to make requests on behalf of the user.

Let’s get started. I went ahead and created several accounts within Gruyere to demo the attack, in this case Travis will be the attacker.

To create a web app worm first you’ll need to discover a vulnerability within a web app that allows you to insert javascript. Luckily the “New Snippet” functionality will allow us to insert javascript. Now to find vulnerable input that allows you to insert javascript may not be that easy. In order to successfully insert javascript you’ll need to be able to insert certain characters such as “<” and “>”. One great tool to find these characters which will in turn find vulnearbilities is Firefox addon named “XSS Me”. XSS Me will tell if an input will allow certain characters. So now that we have vulnerable input how do we get this worm started? As the attacker I will place the following link into a new snippet.

Now all I’m doing here is creating a link to my evil code, to create a worm you don’t have to keep your evil code in another location you could insert all the evil code you need into the vulnerable web app itself. Most of the time inserting all of your evil code into the app itself would be ideal but it really depends on what the vulnerable app will allow you to do. Now that we’ve inserted a link to our evil code what exactly does our evil code look like, below is the source code in evil.html.

Now let’s break evil.html down line by line. All the magic is happening in line one. The first thing that is written is the html paragraph tag “<p”, this is done specifically for this app because anything after the <p> tag would allow other characters. Next is the html body tag with an “onload” action. An action in malicious code is common so that the attacker perform other steps, another common action event is an onmouseover event. Once the page loads it will call the “Wait” function, we’ll come back to that in just a bit. After the wait is the image tag (<img>) to make the XSRF request for me. The request is to add a new snippet to whomever clicks on the link. In this case if a victim were to click on my link it would create a new snippet for them with a link saying “kitten videos”. To add a new snippet within Gruyere the url would be the following

Anything after the equal sign would show up as a new snippet so I inserted the following “malicious” snippet

So what does all that mess mean? If you take all that mess and url decode it’s the following.

In this case I had to url encode my attack so that it would work, this is not uncommon when performing these types of attacks. So as the attacker I’m placing a link inside a new snippet for the victim that says “kitten videos” but that link is still pointing to my evil.html. Now let’s get back to the wait function. I won’t break it down line by line but what happens is when the page fully loads the code will jump to the wait function on line seven. After that setTimeout will execute after one second which calls the Redirect function, the Redirect function will redirect the user to the home page of Gruyere. The whole point of everything after line one is to simply redirect the user back to the homepage after the attack. So now that we have planted the seed of attack let’s see what happens when Alice clicks on our evil link.

Just by clicking on our “evil” link Alice created a snippet that she herself didn’t write, it was our malicious javascript that created the link. Now let’s login as Bob and click on the “kitten videos” in Alice’s snippets.

Bob has now updated his snippets just by simply clicking on the link in Alice’s snippet. You can now see how this can snowball much like other web app worms have spread as well. So in only a few lines of code I have created a worm that will replicate throughout the application infecting whomever clicks on my malicious link. The twitter worm was very simple as well. I could have just as easily made it that if a user were to simply view my snippet that they would get infected as well. Once you allow javascript to be inserted into your app that are a number of things an attacker can do to manipulate your application.

Hopefully this small write up at least some what explains how web app worms get created and how simple they can be. Developers of major applications such as twitter need to better test and review code they have written. As one of my links points out a seventeen year old kid exploited the mighty twitter, just goes to show you how well major applications are focusing on their security. As a user I would never click on a link that you don’t trust and turn off javascript for web apps that don’t need javascript in the first place. If another worm pops up in twitter or facebook I won’t be sad.

XSS-Me is one of the tools in the series that helps to find cross site scripting (XSS) vulnerabilities within web applications. The tool works by locating forms within a web page then tries various inputs into those forms to see if the inputs on that page are vulnerable. A screen shot of how the tool should look inside Firefox can be seen below.

Now all you have to do is click “Run all tests” and let XSS-Me do its thing. Keep in mind that XSS-Me will also find any hidden forms within a page as well. So this is how things are suppose to work but you’ll eventually come across a page that has forms but XSS-Me doesn’t detect them, this is because the page you are viewing has frames. A good example of this is Chris Rohlf’s site seen below.

From the screen shot you can see there is a search form at the top of the page but XSS-Me doesn’t detect its presence. This is because the search form is wrapped inside of a frame. A quick little tip to get around this problem is to open the frame in another tab/window. All you have to do in Firefox is right click on the frame then select “This Frame > Open Frame in New Tab”. A screen shot can be seen below.

Once you have the frame in a new tab XSS-Me will detect the form as normal. This can be seen in the screen shot below.

This same technique will apply to the SQL Inject Me tool from Security Compass as well because it also tries to search for forms within a web page.

This tip was passed along to me by Sahba Kazerooni who works at Security Compass. I have no affiliation with Security Compass but I met Sahba and some other Security Compass employees at a conference and they were all down to earth guys who had great knowledge and experience when it came to information security. So thanks for the tip Sahba and hopefully this tip will help others secure their web applications as well.

It’s taken me a couple of days to recover from Carolina Con. I knew it was going to be a riot with all the alcohol in walking distance. Now that I have my equilibrium I can post my presentation on Layer 7 attacks. My laptop and the projector weren’t working well together so I had to borrow Nick Fury’s laptop which didn’t have all the tools I needed for the presentation, so I wasn’t able to present the second half of my talk. I’m hoping this video will compensate. Keep in mind that my total presentation was going to include this video (scenario 1, cross site texting) and my previous video post of analyzing cookies (scenario 2). One thing you won’t see in this screen cast is that during the presentation I used a volunteer from the audience to prove that an attacker could text himself the username and password of an unsuspecting victim. Luckily apples from the HTS crew let me spam his phone with my demo and all he got was a t-shirt, a kick ass Carolina Con t-shirt that is. Well I had a great time and I’ll definitely make it back next year. As always I would love to hear your comments and feedback.

travis:~$ cat BigUpsMuchRespect

1. nc2600
2. txs
3. wxs
4. Deral Heiland
5. Sahba & Dan @ Security Compass