After releasing my fuzzer I realized I had never really talked about the breakdown of the different charsets for the top 100 websites. I did a quick poll of the top 100 alexa listings (granted there’s some overlap and Alexa really isn’t a good measure of a lot of things, but I just wanted a quick test). I took the top 100, parsed it apart and graphed it out:

Click to enlarge.

Variable width encoding is interesting when you take the various encoding methods in context. As more and more encoding methods are used the fuzzer will have more need. It’s pretty complex to do this sort of testing with any other method. Some of these encoding methods are not very common, others are. It’s interesting that it’s so diverse.

The “Unknown” section is the websites that didn’t have a charset, or failed out because they didn’t allow the request - it was just a quick poll. This could become more and more interesting as we uncover more issues with the various encoding methods - all of which will be much harder to stop as they will involve more complex filtering (restricting the ASCII ranges for instance).

Jaimie Sirovich is at it again with his scanner. This time he aimed it at some .edu domains. The risks aren’t that high compared to the reward for the SEO community. For search engine optimization it’s really helpful to have .EDU domains. In this case, using cross site scripting is particularly useful for hijacking page rank via HTML injection.

One thing I think is interesting is how close XSS and SEO HTML injection really is. Really, the XSS cheat sheet is not designed for straight HTML injection. Primarily all you are interested for in SEO is how to either a) redirect or b) increase pagerank by getting sites that have good pagerank to link to you. Persistance is better than reflection but it appears anything will do. For all their similarities the major difference that JavaScript isn’t as important as links is a pretty substantial difference.

The fact that Harvard is full of XSS holes isn’t that interesting as practically everything is, but the fact that cross site scripting is being actively used by bad guys is. The SEO Blackhat forums has a number of real world examples of where SEO experts are using these exploits actively. If you can afford the $100 a month it’s worthwhile from an academic standpoint, or if you are trying to monetize your own traffic better.

There’s a thread on the forums where Kyran describes an error message that Opera popped up when he attempted to put HTML into the URI field. I was amazed because I hadn’t seen any browser even start to deal that that issue. From an XSS prevention standpoint it seems like a very forward thinking idea. However, alas, it was just some weirdness.

When the url http://<BR> is entered Opera responds with the following text:

The URL http://<BR> contains characters that are not valid in the location they are found.
The reason for their presence may be a mistyped URL, but the URL may also be an attempt to trick you into visiting a website which you might mistakenly think is a site you trust.

So anyway, it’s just some weirdness, and it doesn’t apply to you entering HTML as a query string (something that actually IS a security risk), but it’s still an interesting concept. One thing is sure, despite all the best tools, developers just don’t understand the problem yet. Why not take it out of their hands and put the onus on the browser community to fix the problem on their behalf? Of course this would break a ton of applications in the same way that it did when Internet Explorer turned off support for basic authentication in the URL field to slow down Phishing schemes. But is it worth it?

Of course there will always be ways to circumvent those issues and there will always be other encodings, and don’t get me started on DOM based where I am possibly just entering a small peice of JavaScript and no HTML at all, but the point isn’t to solve the issue necessarily, but to make it significantly more difficult, or to limit the issue.

Well, I am finally doing it, I’m releasing my stupid XSS fuzzer (duly named XSSFuzz). I’ve talked about it, fretted about it, and hated it long enough, and now it’s time to let you see for yourself how crappy it is. Yup, this is just about the worst contribution I’ve ever made to the web application security field, but it does have one valuable purpose. It’s particularly useful for identifying variable width encoding issues - a part of XSS that has had not nearly enough research done. Here’s the XSSFuzz screenshot.

What XSSFuzz is for: It’s for finding new vectors and testing those within the context of multiple encoding methods. One of my least favorite thing is to edit, save, alt-tab, f5, alt-tab, repeat. This dramatically speeds up my own testing, so if anyone else is working on this they should find this useful too.

What XSSFuzz is not for: It’s not for anyone who doesn’t really know their way around XSS. It’s not for testing many different chars and enumerating them against eachother - sorry, I just didn’t have time to build that. It’s also not for testing encoding methods that don’t support HTML properly (UTF-16 and UTF-7) because those mess up the HTML required to verify the tests in the first place.

There is no manual. If you can’t figure out how the program works you probably shouldn’t use it anyway. It’s really a pretty advanced and pretty difficult to use program, but you should be able to figure it out without editing the source code. It is written in PERL due to the rapid prototyping, and it is definitely vulnerable to XSS (so don’t throw it on a production machine without securing it somehow). Anyway, download the zip file here and feel free to give me feedback. No promises that I’ll do anything about any feedback I get.

V-Wall sent me a pretty interesting email today about an XSS vulnerability in wapsilon.com. Generally I don’t bother posting these sorts of things, but this one was fairly interesting from a web application security perspective for a few reasons. One, it’s on a WAP site and I really am wondering how XSS will invade other forms of browsers, including those on handheld devices. Secondly it’s interesting because of the particular vector V-Wall used. The malformed IMG tag.

OK so i been doing abit more looking into things on www.wapsilon.com (a site used to surf wap sites) what i’v been looking at is using wap apps to run XSS attacks. An i have found one you may be interested in here.Ill give you the basic over look first then go into it more.Ok so we have www.wapsilon.com that is used to surf wap sites, Ultimatekaos.co.uk is a wap site i used in my tests, its a simple wap chat site, iv been able to use the pm system on there an have www.wapsilon.com run my XSS code.So now more detail on Ultimatekaos.co.uk, like i said its a basic wap chat site, ya can use the forums, send pm’s to people an go in chat rooms etc. Now i first found there me be a change for using code injection on the site when i was trying different input an sent myself a pm with the text ” <> &quot (no speech marks) an when i went to read the pm there was a error, i was nicely shown the resulting code, an sure enough sat there was my <>. To make sure it was code id injected i did it again but this time used ” < hello me > ” (no speech marks) an sure enough on trying to read the pm i got a error an shown the code, an there sat my code. I made my way to your site an made a list of the vetros that would work with firefox, an went through them trying one by one. The one i came across first that worked was alert(document.cookie) now the code was run an sure enough i got a window BUT it seemed there was no cookie set, so just to check where the code was running i change the code to alert(document.location) which when run showed www.wapsilon.com being the place where the code was being runSo seems as www.wapsilon.com transfers the wap page code through it app for reading an decoding etc, the SCRIPT tags get passed as code to be run by www.wapsilon.com

Here are his screenshots. input vector and the XSS vulnerability.

I know there has been some vulnerabilities in some PDA devices thus far dealing with CSRF in the internal device itself (stealing contact info or other nefarious things) but as PDAs become ubiquitous (as they already have in the asian markets) this will become a bigger and bigger issue. Hold on to your hats!

Don’t take my word for it, Networkworld.com has just published a paper describing XSS as the top security risk of all vulnerabilities. According to MITRE it’s true! Go figure! Well I can’t say it surprised me too much to hear it, but it was surprising to hear it happen so quickly. Yah, it may not be as obviously dangerous as other attacks, because it in of itself is not an attack, it is a vector by which to enable other attacks.

However, it’s great to see “the little vulnerability that could” finally grow into the largest single threat that faces the internet today. As Jeremiah Grossman and I laughed about, we should make a tee-shirt that says “Veni Vedi XSSdi” - that is “I came I saw I XSSd”.

About once a month or less I am actually amazed by something in web application security. Most of the time it’s when two technologies that are otherwise not connected suddenly are used against one another. Well this time is no different. Wade sent me a link to a paper he wrote and published but for some reason never made it out into the world. Well this is one of those few papers that amazed me so I’m making it my job to tell people about it. Wade has demonstrated that IMAP is vulnerable to cross site scripting. Wow.

Paraphrasing his paper - he basically explains that by using post you can execute commands against a IMAP server and because it doesn’t understand what you are talking about it actually echos back errors. Those errors are run by the browser and poof, you are now executing JavaScript. This is pretty cool stuff. It’s rare you see HTTP attacking other services for the soal purpose of running JavaScript so that you can gain read access to a host - but there you have it.

I think the most dangerous potential for attack is actually in the situation where a single machine has multiple services on it (HTTP and IMAP in particular) and IMAP is actually hidden behind a firewall (RFC1918). Now the bad guy can get the user who sits behind the firewall using a post submission, connecting them to the IMAP port on the victim webserver. The webserver is immune to XSS in this example, but IMAP is not. IMAP echos back the JavaScript which tricks your browser into requesting data from a different port on the same host (no cross domain restrictions) via XMLHttpRequest. Thereby gaining read access to the host.

Wow. Pretty cool stuff, and pretty straight forward when you think about it. I don’t know if IMAP 4 is vulnerable but IMAP 3 is, so additional testing might be required. This is yet another example of how the internet is basically swiss cheese and by using two completely unrelated protocols you can gain access to an otherwise hardened machine using the administrator’s credentials or from behind the firewall.

I know, it’s a hell of a title, but it’s just about as obscure as it sounds. While messing around with various malformed HTTP requests I found something that is practically useless, but could be scary if anyone could figure out how to exploit it. From a web application security perspective this could be bad, but I don’t know of a way to usefully exploit it given the known holes out there today. So a normal HTTP header might look like so:

GET / HTTP/1.0
Accept: */*
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: www.apache.org
Proxy-Connection: Keep-Alive

And here is how I modified it with burp proxy:

TRACE /?<SCRIPT>alert("XSS")</SCRIPT>
Accept: */*
Accept-Language: en-us
Pragma: no-cache
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: www.apache.org
Proxy-Connection: Keep-Alive

Notice that I removed the protocol (HTTP/1.1) and I changed the method to “TRACE” instead of “GET” or “POST”. Here’s the screenshot. This is just about as un-useful as it gets as I’ve described it. But if you’ve been reading this blog for a while you’ll say, “What about the Flash header spoofing?” I wish that had worked because it would have saved me a lot of wasted time trying. Here’s the problem.

Firstly, Flash doesn’t let you change the method to TRACE as far as I can tell (GET and POST methods only). Secondly I can’t omit the protocol (which is necessary to cause it to be mal-formed enough to cause this to happen). Thirdly it URL encodes the string, which causes it to not render HTML (as the server doesn’t un-encode the string). So, no go using Flash with what I know thus far. However, there may be other ways to do this that I’m not aware of so it’s something to hang onto.

It would have affected only Internet Explorer, on Apache instances with only servers that have TRACE allowed by default (even Apache.org has this, so I’m not too worried about that). So for now, this is not a useful vector, but in the future it may be as browser technology evolves. The reason it’s dangerous (if you could get it working) is that it affects 70% of browsers on about 60% of servers (number of Apache servers as a percentage) assuming they have TRACE enabled (most do). It’s worth keeping my eye on anyway. Sorry, it’s been a crazy last few weeks.

I got an interesting email today that I thought was worth exploring. One thing I haven’t really explained in much detail is exactly what can be done with XSS. Sure, there are obvious implications, like cookie theft, and defacement/phishing, but what about some other web application security issues? Here’s the email:

is there any other possible application of xss vulnerability, other than showing html text on affected page, that will be visible only on that page and have not change any server files? (or stealing cookies) Can the XSS change/delete pages, add pages, browse admin directories?

If the application itself has the ability to change files, sure, XSS combined with CSRF can do anything that user has access to. I actually responded to an almost completely unrelated issue the other day that got my brain thinking on other issues. Recently someone asked if IP based security had any issues. Here was my email:

Hi, Darryl, this is really more of a network security question than an application security question, but let me take a stab at it. It is possible, although very unlikely that they can spoof an IP packet to run some command on the server. They would be doing so blind though as they wouldn’t see the responses. There is a fairly good article here: http://www.cosc.brocku.ca/~cspress/HelloWorld/1999/03-mar/spoofing.html

This really isn’t super practical on a lot of modern systems because they do a better job of reducing the predictability of the ISN to create the fake three way connection. Also, if the server is under any sort of load it makes it more difficult. Also, the attacker would have to know exactly what to craft to make that happen (so unless it’s open source, that simple fact alone will make exploitation much more difficult).

So yes, theoretically it’s a bad idea, in practice it’s pretty difficult to exploit from a black box perspective. Beware people on your local LAN though, they’ll have a much easier time exploiting than an outsider would as they have visibility into packets in both directions if they are sniffing the network.

So after completely blowing this out of the web app sec world and into the network security world I realized I am missing a fairly major issue which is CSRF via XSS. Because IP based rules rely on one thing (the IP address in question performing the task in question) all it requires is that you get the IP address to perform an action for you.

So let’s say you have an web application with a rule built in to not perform a function based entirely on an IP address validation. Let’s say I can get a user from the same IP address (in the case of a company or small company behind a NAT) to view a webpage under my control. At that point the victim user should connect to the function and perform the action on my behalf.

There are dozens of other applications (like the JavaScript intranet port scanner for instance) but this is one I don’t think I had discussed before. But like any form of authentication IP address verification is just one more issue that can be overcome.

Eric Farraro found another fairly complex XSS exploit in Google - again. I applaud his technique as it was fairly complex (not your standard variable tampering).

Google has since taken down the offending service with an error that says simply, “This service is currently unavailable. Please try again later.” Self induced DoS by XSS, huh? Removing services seems like a bit of an overreaction, but I guess it was too much of a black eye to have an exploitable service sitting out there until they could fix it properly. Additionally, there is another random error message created by Google when you go to this URL, saying,

We’re sorry…

… but your query looks similar to automated requests from a computer virus or spyware application. To protect our users, we can’t process your request right now.

We’ll restore your access as quickly as possible, so try again soon. In the meantime, if you suspect that your computer or network has been infected, you might want to run a virus checker or spyware remover to make sure that your systems are free of viruses and other spurious software.

We apologize for the inconvenience, and hope we’ll see you again on Google.

The odd part is that this cross site scripting exploit was reported on the 14th (or before), and here it is the 16th and the service is still down. Why would it take more than a few hours to fix this - it took 24 hours or less each time before? I guess the best and the brightest are still stumped by HTML injection mitigation. Either that, or this time it’s different. Interesting. Either way, it should be a side note that this is a possible outcome of XSS - severe self induced outages.