The results are finally in for December’s web application security professional survey! And I have to say I was far more impressed by these results than the previous results. Not because the questions were better. Not because the questions included references to ha.ckers.org and sla.ckers.org. No, as if that wasn’t enough, Jeremiah threw in a bonus question asking what people found to be “The most valuable web application security tip/trick/idea/concept/hack/etc you learned this year (2006)?” The results were very interesting.

I think it’s fascinating reading who said what. And thank you everyone who mentioned ha.ckers.org and sla.ckers.org. Trust me, we love you too, guys. But what I thought was really interesting was some of the comments, like using VBScript to test XSS since it isn’t case sensitive. And using UTF-16 to bypass filters (there is so much work left to be done in the encoding methods it’s just silly).

I really hope Jeremiah continues this and evolves it to ask more of these types of questions. Getting the real dirt on some of the tricks of the trade can help the entire field. Anonymous or otherwise, the tips are incredibly useful! But cool stuff, and thank you to Jeremiah for putting this together. I think anyone working in the space will probably be interested in this stuff.

Luny wrote to tell me about a new XSS worm that’s hitting Adultspace.com (Adultspace.com is to MySpace.com as AdultFriendFinder.com is to Friendster.com - if you remember your SATs). Anyway, it uses a cross between XMLHTTPRequest and the forums themselves to create the attack. It doesn’t use filter evasion. Luny attached a zip file if anyone wants to take a look at the source.

The attack is designed to make you friends with other people so that you can see their naked photos. It affects both the forums and the bulletin boards and because of how it’s written it’s pretty easy to detect.

I guess there are some perverts out there who happen to be pretty good JavaScript coders. Who knew? This lends credence to the fact that community sites are intrinsically more dangerous than other sites. If you have pictures of yourself on there wearing nothing more than a smile you might consider taking it down until they ramp up their security.

Thanks for Luny for the tip!

Jeremiah has been on a roll lately. Not just releasing some of the old stuff but he’s actually be coming up with some very cutting edge new stuff too. Most recently he’s found that you can detect if someone is logged in or not by trapping JavaScript errors created by including the HTML page as script. Crazy!

Click here for the PoC (you must be using Firefox and have JavaScript enabled). He demonstrates the vulnerability in Yahoo Mail, Gmail, Hotmail, Google, MySpace, Blogger, Flickr, My MSN, and SearchAppSecurity Techtarget. This allows him to perform a similar function to the CSS History hack, except this time, SafeHistory isn’t going to help you since it’s JavaScript only.

We talked about this at some length and we believe that it would be pretty easy to build custom scripts for almost any website. So much for the same origin policy. The really scary implications are that the way this is built it’s not just a binary operation. It could easily be expanded to detect multiple states of a web-page. You would have to know what it would look like in those various states, but it’s definitely possible. Great job, Jeremiah!

Dear Search Engines,

I’ve worked for huge companies for many years. Each have their own unique issues. One issue they all have in common is you. You crawl our sites and expect us to know better and be able to react to that in real time. You expect us to know what we don’t want crawled and you expect us to be able to conjure up a robots.txt file put rel=nofollow Meta noindexes or whatever to satisfy that need.

Another issue that all the companies I’ve ever worked for have is slow time to develop and release anything to the website. If I know there is an issue a) I have to explain it b) get buyoff from engineering/business units/execs c) get engineering to build the document d) merge the code e) QA it f) wait until the next build/release and then poof, just like magic we may or may not have fixed the issue depending on if QA and engineering did their job right. If not, the cycle continues.

Here’s a crazy thought. Why don’t you let us upload our robots.txt to you guys? Make us put some crazy hash in a file somewhere to prove we are who we say we are, but let us tell you immediately what no not index, what to not follow or otherwise waste our bandwidth doing. I ran into a situation today where any reasonable person could have immediately told you how to fix the issue, yet it may take weeks or months to fix the problem instead of one guy in a few minutes uploading one file to tell you not to do XZY. You allowed us to do things like upload site-maps, why not let us tell you what we DON’T want you indexing? I know, where do I come up with all this crazy talk?

Tell you what, search engines, I’m going to let you think on it while I grind my development resources to a halt trying to keep you off of certain areas of my company’s site. Let the patent wars begin.

-Love

RSnake

Apparently this is true, although I can’t for the life of me figure out why this should be allowed. I ran across an article at DCortesi’s site talking about how Firefox has delegated their security to Google for installation of the Google Sync XPI. Pretty scary actually. What this means is that if an XSS hole were ever found in any whitelisted domain (including XSS in their server, MITM through your proxy server etc…) Firefox will happily allow you to download xpi files. I’ve talked with a few people about this off and on in a different context of loading an xpi file into a data: directive on the whitelisted domain. Yah, that’s scary. This is worse.

This sort of delegation of authority to other domains that you haven’t whitelisted is bad beyond the data directive because the size is unlimited (I have a feeling the data directive has an upper bounds although I have been able to get a data directive the size of 4k before so maybe not). Additionally you can load multiple files and the URL is much smaller if you don’t have to use the data directive. Anyone have any references on the upper bounds?

All of this seems especially bad when Google hasn’t been particularly good about keeping their site bug free. But it’s not just that Google is untrustworthy. You could turn any site into a delegate the way Firefox has been built - as long as you can force a redirection. If you can force the redirection it will allow the file to be downloaded. I haven’t tested this but I’m sure someone on the boards will. I’ll be curious to see if it’s really as bad as I think it is. The web just isn’t safe enough to allow delegates. I guess it’s time to clean out my exception list until I need to install something again.

This yet may prove my theory wrong - that it’s not the browser that’s flawed, it’s the plugins. In this case it definitely is the browser.

It’s just been a week for Google issues, hasn’t it? Well today is no different, except instead of finding exploits in Google’s social networking product (Orkut) this one is in Google proper. I got an email from Hong, in China. He found a fairly obscure and difficult to exploit cross site scripting vulnerability in Google’s website. Here’s how it’s done.

First, click here to pre-load the XSS vulnerability onto Google’s page. Then click any of the links in the lower right hand corner, such as “Groups” or “Adwords”. You will see an XSS alert box if you have JavaScript turned on. While obscure and difficult to exploit, this points to how big companies don’t spend the proper time doing security auditing on their websites during development and QA.

Nice work, Hong! Btw, in case you weren’t following the boards, I’d highly encourage anyone interested in knowing more about Google’s ethics to visit this post by Jeremy Zawodny.

Rajesh Sethumadhavan posted another vulnerability in Google’s Orkut. This one is a tad more obscure because it requires user input (clicking a link) to execute the exploit. Here’s the disclosure:

1)Orkut Invite XSS:

The flaws are due to improper sanitization of inputs passed to ’show’ parameter in GET request
——————————————————————-
http://www.orkut.com/Friends.aspx?show=group1);alert(document.cookie
——————————————————————

Demonstration:
Note: Demonstration leads to your personal information disclosure

- Login to your orkut account
- Paste the above URL
- Click on ‘delete group’ & ‘ok’ button
- Orkut Cookies will get displayed

I’ve never been a big fan of social networking sites for the (lack of) security aspect. With the recent rash of XSS worms out there, these sites should probably start considering these issues as serious. Since Google doesn’t appear to have the required resources in-house they should really consider hiring outsourced help to fix them. At least they are getting some input from their users, even if they aren’t able to find their own security flaws. Until then it’s probably still a good idea to steer clear of these websites from a consumer perspective.

Every week or so I get the same question about XSS. What’s the worst thing cross site scripting can do? We’ve tackled the question from a somewhat crippled perspective, which is that we can attack the site you are on, or we can attack your intranet, or we can make you attack someone else on our behalf, etc… That might not sound crippled but it is. It’s dealing with XSS as if it were only one bug in one place, when reality the way the web is built, XSS is practically everywhere. It’s far more prevalent and easy to find than any other vulnerability.

On the boards yesterday, Maluc had a really brilliant thought. It’s not that you can XSS just one domain on which you find the vulnerability. But once you have control over the user’s browser through one XSS hole you can exploit others on other domains. This can lead to a massive cascading effect where you can have one XSS exploit that uses XSS in hundreds or even thousands of other domains to steal all the credentials and identity information that it can. As we’ve found nearly 1000 unique XSSs in huge companies, there is no doubt way way more that we haven’t touched. The only thing slowing this down is detecting which ones to try.

Not knowing which XSS to go for too can be mitigated using Jeremiah’s CSS hack. If the user has been to abcbank.com chances are they’ve logged in there, and chances are you’ll have a more successful time attempting to steal their credentials through a website they’ve been on. The CSS hack only takes a second or less to iterate through a thousand links, so this would take very little time in the user’s perception. In this way you can exponentially increase the information theft through a single web-page the user visits.

Taking this one step beyond Maluc’s original idea, let’s say you find a link from the website you’re on to another website that you have found a XSS hole in. Instead of loosing control over their browser once they move from one domain to another, why not change the link (to the homepage of xzysite.com) to another link on xyzsite.com that has an XSS exploit in it and then use XMLHTTPRequest with an XSS proxy to continue your attack.

If the user is currently using Internet Explorer, you can even try to re-write anything that goes to another domain into Flash using the Expect header or maybe use the mhtml vulnerability to get some cross domain leakage or to find other sites that may not be obvious to attack (the URL may not be right in the latter example but really, who watches the URL bar on every request?). Now you’ve got a potentially interactive XSS shell that follows a user across domains. It doesn’t matter if it’s not persistent, it moves with the browser on each request, or mimics what the browser should see by using XMLHTTPRequest and re-writing the page. Beautiful.

So… what’s the worst thing you can do with XSS? Steal every piece of sensitive information you’ve ever inputted or will ever input on any website you’re authenticated to. Yes, it’s potentially that bad.

Generally I have banner ads completely turned off, but I was doing some research with them last night and I found something interesting. I guess I’ve been behind the times with some of the recent trends with contextual advertising. Shame on me, because like aways the adult industry has taken the lead with highly targeted contextual advertising using Geo Location. AdultFriendFinder (nsfw) is a service trying to match kinky people up with other kinky people. I have a funny story about them, but I’m getting ahead of myself.

So they have taken to modifying their banner ads by showing you which women are near you using Geo location. Here is a dump from the banner ad locations as taken from a machine up in Northern California (San Francisco):

freakychick6902 18/F Richmond, California

northernkitty 32/F South San Francisco, California

dmagirl 34/F San Francisco, California

bgirl5 22/F San Rafael, California

1girl4u68 22/F Vallejo, California

Pretty good, huh? All of those places are within a 10-20 miles of the machine this was pulled from. Click here to see the JavaScript output for yourself. With something like this it becomes trivial to leech this information without actually having to build a IP to Geo tool yourself. Since it’s in JavaScript instead of a dynamically constructed image you can either overwrite the document.write function with your own, or let it output into a hidden div tag to make it less obvious what is going on. Leave it to those porn guys!

Anyway, my unrelated AdultFriendFinder story is that I got a random phone call from them at some point. They had found my resume from somewhere and were claiming that I had submitted it to them (I think I would have remembered doing that). They were trying to con me into working for them. Uhm… no.  Believe it or not, I am not that easily socially engineered. Cool technology, but alas, I think I’ll just leech it instead.

Rajesh Sethumadhavan is on a roll. This time he’s found a number of XSS issues in Google’s Orkut. As we’ve seen in over the last year or so on MySpace the potential for malicious worms is extremely high with social networking sites. Given the fact that Orkut isn’t as open a system as MySpace doesn’t actually change the issue. Probably the only saving grace for most of the people reading this is that Orkut isn’t that popular in the United States anymore. However, it is extremely popular in Brazil and other countries around the world. Here is Rajesh’s vulnerability (modified for formatting, downloaded the images, and brevity, etc…):

Overview:
Orkut is an Internet social network service run by Google and named after its creator, Orkut Büyükkökten. It claims to be designed to help users meet new friends and maintain existing relationships with pictures and messages, and establish new ones by reaching out to people you’ve never met before.

Orkut service is vulnerable to Cross-Site Scripting and HTML Injection. This is caused due to improper validation of user-supplied inputs.

Description:
A remote attacker can craft a GET request with the XSS payload as demonstrated below. When the victim clicks on the GET request the payload will get executed which result in stealing of cookie, IP info, refer info, browser information, clipboard content, operating system info, hardware Info, modification of page or html injection, url redirection, port scanning of the network, and even phishing is possible.

1) Orkut Invite XSS:
The flaws are due to improper sanitization of inputs passed to ‘continue’ parameter in GET request
——————————————————————-
http://www.orkut.com/Invite.aspx?continue=javascript:alert(document.cookie)
——————————————————————
Demonstration:
Note: Demonstration leads to your personal information disclosure
- Login to your orkut account
- Paste the above URL
- Click on BACK button
- Orkut Cookies will get displayed
The similar way HTML injection is also possible.
——————————————————————

Solution:
Orkut can improve their filters by disallowing certain characters like " <>/\?&`~!@#$%^*()[]|;:"' " in user input URL.

Screenshot:
http://ha.ckers.org/images/orkut-xss.jpg

Impact:
Successful exploitation allows execution of arbitrary script code in a user’s browser session in context of an affected site which result in stealing of cookie, IP info, refer info, browser information, clipboard content, operating system info, Referer info, hardware Info, modification of page or html injection (temporary webpage defacement), modification of page title, hijacking page flow, url redirection, port scanning of the victim’s network, and even phishing is possible. Impact of the vulnerability is network level.

Rajesh also included another XSS that has since been fixed (I removed it simply for brevity). But you get the point. Orkut is vulnerable, and therefor anyone who uses it is also vulnerable to the impacts that Rajesh outlined above. Nice find, Rajesh.