So the problem I have in my job and maybe others do as well is that when assessing a web application for vulnerabilities you want to throw automated tools at it first to get the low hanging fruit. So you get the results back and you have some good findings but you’re not exactly sure where that finding resides inside the application. Meaning first click here, then here, then here, and modify parameter X. It’s not crucial to know this because with burp or any decent web proxy we can replay that request to retrieve and prove the vulnerable results but when dealing with laymen and even developers you have to hand hold them through the exploitation process via the browser as much as possible hence the need to know where in the application the vulnerability exists.

In big applications simply knowing a what GET or POST request is vulnerable may not tell you where the vulnerability lies. Let’s say the scanner reports back that http://example.com/xskw/requestID?=blah is vulnerable, well this is a generic URL without much context so it’s not obvious where you would have to browse to stumble upon that request. It’s even worse for POST requests because going directly to the URL without the parameters can produce errors within the application.

Let’s walk through an example of using the burp intercept feature to find where scanner results are located. I’ll be using an intentionally vulnerable web application named Peruggia found within the owaspbwa project which is a great project to learn web app testing. So I ran the active scan against peruggia and got the following results.

I’m going to focus on the highlighted cross site scripting vulnerability in the screen shot above. I picked this request for a number of reasons but first let’s take a look the details of the request below.

Here we see it’s a POST request and I wanted to focus on a POST request because some of the challenges faced with these requests. In the top third tab we see the response was redirected which means we’ll get a 302 status code. If you were to copy and paste the URL into the browser and make that request you’ll be redirected to the home page. This is the nature of POST requests we can’t just put the URL into the address bar and be take to that location. Because of this it can be hard to determine where in the application the vulnerability exists. Especially for XSS (cross site scripting) vulnerabilities I like to obtain screen shots of the alert box to prove to the customer that I was able to exploit the vulnerability. With a GET request this is easier but POST requests add a level of difficulty.

Let’s walk through an example to understand the challenges. I’ll be starting out on the about page of the Peruggia application. Next I’ll paste the URL from the XSS finding into the address bar.

After I enter this request I get redirected to the home page.

This is also reflected in burp where we see the 302 redirect status code that sends us back to the home page.

So the challenge is to find that “comment” parameter that burp flagged as vulnerable but without a simple GET request this can be difficult. I didn’t pick the greatest example because the “comment” parameter shouldn’t be that hard to find in this application because it’s fairly small and the parameter is actually providing some context, adding a comment, which doesn’t always happen. So for this example let’s ignore the big comment box on the home page and pretend we didn’t see that.

We’ll now set up a rule inside the proxy intercept to alert us when we stumble across the vulnerable “comment” parameter. Let me explain the term stumble for a second. When I get a result back from a scanner and I’m not sure where it’s located inside the application I’ll typically start walking the application and monitor my proxy history to see if that parameter was passed within a request. This can be a pain in the butt so setting up a proxy intercept rule can help automate the process. The rule is somewhat counter intuitive because we’ll leave the intercept on the entire time and let it catch when it sees our parameter. In this case we’ll disable the default file extension match rule and add our new rule to look for the parameter in question. Below is the rule I setup to catch the vulnerable parameter “comment”.

Now the next thing is to start browsing / walking the application and the proxy intercept will automatically alert you when you come across the vulnerable parameter. So while walking the application I decide to post a comment on a picture to ensure I’m touching every functionality of the application. My intercept is on with my new rule waiting for it to flag the vulnerable parameter.

After I make this request my proxy starts blinking and alerting me to the fact that I’ve come across the “comment” parameter.

Unfortunately for large applications it may take some time before you stumble upon the proper vulnerable parameter but hopefully this will help you out when trying to pinpoint the location of automated findings. Of course once we’ve found the vulnerable parameter that the automated scanner has found we’ll want to capture a screenshot of the exploit and this case we’ll need to document that we’re abe to execute javascript inside the application. So now I’ll capture that POST request again and insert the classic javascript alert message.

And now the alert message proving to the application owner’s, developer’s, and customer’s that executing javascript is possible.

XSS FTW. Hopefully my little small tip will help you when trying to hunt down where in the application an automated finding resides. Happy bug hunting.

These add-ons are mainly related to web application security, you see these types of list related to firefox add-ons but these are the ones that I think are the most helpful. Firefox has a nice category called web application security penetration testing that has a lot of the plugins I’ll mention.  Not all plugins in this category are worthwhile which is why I’m sharing my list.

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.

When I say web app worm I mean a web site specific worm such as twitter. Twitter has been picked on (they should be because it’s a meaningless app) when it comes to web app worms so why stop now. There are other types of worms that could include web servers and databases but that won’t be addressed in this write up. The web app I’ll pick on for this example is Gruyere. Gruyere is an intentional vulnerable application that a handful of folks over at google wrote to point out some of the major vulnerabilities within web applications. Gruyere is very twitter like so my example would be relevant to other applications that function in similar ways.

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.

Security Compass has created a series of Firefox add-ons that aid in performing web application assessment. These tools are a great convenient way of finding vulnerabilities within web applications. I do want to point out that even though these tools are useful there is no guarantee all vulnerabilities will be found.

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