GNUCITIZEN

Automation - it is the power to change the boring repetitive task into something that is more fun. No wonder why, we as human beings, seek for automation in all corners of our lives. It is so unique to us. It is so us.

Automation is also what we try to do in security. There is a security vulnerability; we write an exploit for it. There is a defined method of exposing thousands of machines to malicious activities; we write a worm for it or at least a vulnerability assessment engine. Every bit in the Eco System of our virtual world is based on automation and everything we do is automated, for ease. As such, I would like to talk about automation in the world of XSS and web technologies.

One thing that nobody manged to succeed with the traditional (executables) worms is a mechanism for finding new vulnerabilities and exploiting them on the fly. This is because the process will require an AI that understands what debuggers are, how processes co-exist, how the network functions. Putting something like this into an executable is complicated; building the pragmatics and semantics that are required is even more.

I have been thinking about this kind of stuff for quite a while and now I certainly can see that this type of automation is not that hard to achieve with web technologies after all. The rest of this article briefly discusses a simple method for locating Cross-site scripting issues on the fly. Similar approach can be implemented into JavaScript based XSS detection tools.

The problem with locating XSS vulnerabilities from the browser is again, like all other problems in this field, hidden inside the same origin policy. Simply put, pages from one origin cannot access content from a different origin. That means that first of all attackers don’t know what kind input channels (GET and POST) can be exploited, and second of all they don’t know how the get the result back when an XSS is detected because they don’t have access to the targeted resource. So, when both of these obstacles are successfully passed, we will end up with automated XSS detection engine that works from the browser. In fact it will work from every page or media content that supports JavaScript.

Solving obstacle one is hard. How can we know what input channels an application may posses? There might be some forms, but we don’t know about them. We can brute force names but that is slow and kind of lame. The simplest thing I come up with is to proxy the page through Google Translate and get the content by using the technique implemented in the JavaScript SPIDER proof of concept tool. Although it is slow and far from perfect, you must agree that it is a possible vector that can be employed. That’s not all.

Input channels, such as GET fields, can be exposed by querying our main web content librarians. We can use the Google AJAX Search API with the following query “site:<targeted site>” and the search engine will give us tons of URLs some of which may have GET fields after the question (?) mark.

So the input channels are identified, now is time to get to the real thing: detecting a vulnerability. This task of course needs to be divided into two sub-tasks: find a generic way to check for the presence of a vulnerability and build a pragmatical approach to automated the process.

Luckily, task 2.1 is easy to achieve with JavaScript. With XSS we can simply inject JavaScript code into the targeted page (this one is inside an iframe) input channels that will set certain bits on the parent identifier in the following way:

document.parrent.location.hash = "vulnerable";

Meanwhile, the parent is set into an interval loop that will check for any changes like this:

setInterval(function () {
if (document.location.hash == "#vulnerable")
  alert("got it");
}, 2000); //every two seconds

As you can see detecting XSS vulnerabilities is simple while SQL Injection is probably not possible or very hard to achieve. Yes, we can use again Google Translate to do the dirty job but the process will be slow and a bit annoying. Moreover, a generic SQL Error parser needs to be implemented in order to detect weather the attack was successful and then the exploitation vector needs to figured by the application on the fly. That ask for a lot of code. So, XSS are easy to detect using this method, while SQL Injection is not.

Unluckily, task 2.2 is not easy to achieve. Why you may ask? Well, the application needs to carry a solid database of common ways of injecting JavaScript. All variations of the following must exist

"><script>document.parrent.location.hash = "vulnerable";</script><!--
" onload="document.parrent.location.hash = 'vulnerable'; void 0;"><!--
...

Once we have that we can implement a simple brute force technique on all input channels and wait for the process to finish. Thankfully, RSnake is hard working on his XSS cheat sheet that can come quite handy in this type of situation.

Some people may object that all this is gibberish; that this is just not flexible and more over it is not feasible. Well, you might be right for now but you will be absolutely wrong in the near future. The more AJAX websites are developed the less the user will jump between different resources. In GMAIL for example, the user does not leave the initially rendered remote resource. This means that if an XSS issues is archived in my account, I most probably be affect for a whole day since I have the page open for that long. Developers are thinking about implementing AJAX based web platforms that have virtual browsers inside. This makes everything a lot more worse if you think about it.

I hope that was helpful. Personally, I don’t have time to write similar type of tool but I will be very happy to hear if someone is up for the challenge.