Archive for October, 2004

Google Cookie lets you go anywhere

Friday, October 29th, 2004

Not surprisingly there’s more announcements of google’s holes - they’ve fixed Aranzulla’s by the looks of things (by stopping any google desktop results from appearing in a web search, good choice) but they’ve still not fixed my google desktop one, although it’s now not exploitable unless you can first get in to the localhost so - look at what happens when getting a cached email message, the search string is written unencoded into the page - </script><script>alert(1)</script> will execute the script, tough to exploit without other bugs, but still shows poor programming practices.

The recent hole again shows they don’t really understand basic security principles - the cookie you get to authenticate you, lasts forever, isn’t tied to ip address or anything, it’s all you need to view gmail, google or anything. People who looked at my sample exploits will note I captured the cookie as part of one of the POC’s - don’t worry if you looked, I won’t be doing anything with the cookie.

The Google Cookie problem is pretty obvious, I’d considered it, but not bothere to check figuring that google couldn’t be that stupid to only use a cookie for authentication without basing it on a hash of other details of the request, I should never have underestimated Google’s ability to get security wrong.

Trying google security again.

Tuesday, October 26th, 2004

Well the Google fix didn’t fix all the original issues I reported, I didn’t mention them in the exploit page as they only apply to a few minority browsers, but they’re there - so I’m trying security@google.com again again, this time copying in two people at google who got in touch.

Not that I hold out much hope, the Google security guy hasn’t responded in the last 5 days to my simple request of how to actually report flaws since the email address doesn’t work (and I’ve heard from two other people who have had a similar lack of response after emailing them)

Hopefully Google will start responding and taking security reports seriously, I don’t hold out much hope, but if the flaws that exist in google desktop are made public, Google won’t be able to get it fixed in hours, people will be stuck with the old flawed, exploitable versions of Google Desktop they have now. If you’ve still got Google Desktop, Uninstall it now!.

Oh actually it looks like Salvatore Aranzulla has already publicised the Google Desktop flaw - whilst not quite the same as the one I found, it comes from the same root cause - Google developers writing untrusted data from the querystring straight into the page without encoding it.

Google, stop releasing products, get all your developers into a room, get some good developers who understand Security to explain it to everyone. Then review all your code and sites, get some tests written, get defensive and sort your security out now, before exploits start actually getting used. At the moment it’s ridiculously easy to find exploits in Google, and they don’t seem to be taking it seriously.

Users - uninstall Google Desktop, make Google a “Restricted site” in IE so script is disabled go to “tools - security - restricted sites” and add *.google.com, other browser users do the same, and start looking for different search or email solutions.

Exploit working again for some?

Thursday, October 21st, 2004

I seem to be getting what appears to be successful google exploits coming in again, I don’t know if this is because of proxy caches, or some google boxes haven’t been patched, or just because the logs are making other requests look like google ones. But a reasonably steady request for the javascript files with google referrers. and then subsequent hits to the steal uri just like the pattern when it was working for me are coming in.

Still appears patched for me though - Netcraft however say they’ve found another though, not surprising, but lets hope google are little faster at fixing it this time - Turns out my 2 years was actually an undersestimate, in May 2002 I posted it to usenet, and that was months after I’d let google know.

My Wordpress implementations was broke

Thursday, October 21st, 2004

It appears both comments and trackbacks were broken, rather annoying, I’ve managed to fix the comments, but I’ve not got time to fix the trackbacks right now. Sorry about that!

Google have finally fixed it.

Wednesday, October 20th, 2004

Google seem to have finally fixed the flaw sometime around 6am today, not bad only took them a little over 2 years, so good to know they’re responsive. Actually it seems from the logs that it made it into the google bug tracking system around 4pm yesterday, so 14 hours from then to fully rolled out is actually quite impressive, what’s not impressive is the failure of the security@google.com address and the lack of any phone numbers to contact them.

Google did eventually get in contact with me by email at around 7PM yesterday, 3 hours after they knew about it and an hour after the bugtraq posting they didn’t seem to be overly concerned and claimed “to be aware of the issue” combined with their lack of thanks of me drawing their attention to it suggests that it was actually a known bug they’d just neglected to fix. They said they’d look in to why my security@google.com emails failed to elicit a response, but seemed mostly concerned about getting me to take the exploit page down - I declined that request, it didn’t seem worthwhile as the exploit had by then been mentioned on lots of other sites, so it would’ve done nothing to aid security.

The fix they put in place is still flawed, it relies on special casing the vbscript, javascript and perlscript strings, meaning other language protocols are still at risk in IE with its multiple scripting language capability. The risk is obviously much lower as very few people have other scripting handlers registered, but it could still be used as a vector to attack a corporate installation with known other script engines. What I don’t understand is why instead of blacklisting various strings, they don’t just require it to start http:// - what other protocols do you want in an image on a customised google?

Hopefully Google will get in touch explain what went wrong with the communication of the issue, hopefully google will realise that a phone number of the security team on the web would also help (After trying to explain to Tesco customer support a few years back that there was a non SSL credit card collection problem and getting absolutely nowhere, I’m not going to call normal people with security issues, they don’t understand them) I don’t actually expect them to get back in touch though, they weren’t exactly friendly. Perhaps not surprising as to them it seemed I went public before informing them, but a trivial hole that’d been there for 2 years, I had to do something to get it fixed.

Phishing with Google

Tuesday, October 19th, 2004

Well, still no response from google about the security flaw, so I’ve added in another more interesting example, this one replaces the google page with a simple form telling the user that google is now a subscription service and asking for their credit card details, then upon submission the info goes to my site, before returning the user to google with a thankyou - only works in windows IE (inserting dynamic script elements is easiest there) For those of you without IE, this is what it looks like:

Screenshot of Google Phishing Exploit

I think this sort of phishing would likely result in a large takeup. Hopefully google will start listening soon, this time I’ve posted to bugtraq too.

Google security flaw exploited.

Monday, October 18th, 2004

I’ve mentioned the google script insertion flaw before, Google don’t seem to want to do anything about it, I’ve emailed security@google.com, but have had no response from them, well I got automated responses (that latest had number #15585565 in the subject no idea what that means).

Google Desktop has made the exploit even more dangerous - because it places the results of a desktop search into the output of a regular google search, the exploit now allows the capturing of information from the local computer - okay it’s not much information, but how long is a password or a credit card number? It’s also able to capture all the searches you make, and the ads/links you click and report them to a 3rd party site.

The exploit is a simple script insertion flaw, the image url of a custom search isn’t sanitised against javascript (well it was actually sanitised a little after my original report two years ago, but in a very incompetent way which suggests they didn’t actually test or understand the issue) so with a link, or a custom form you can inject script into google - which can then load any amount of script from a 3rd party site.

The exploit is trivial, and to get a user to use it, any of the popular “search my site” google forms can do it, or after a link to google . My sample google exploit is pretty poor, it tends to error with some strange timing issues occasionally (the data is still sent though), it only works in IE (the google desktop results are only inserted in IE, but the general security flaw is common to many browsers, it’s not an IE security flaw) but it shows how easily it can be done - it took me half an hour, more malicious users could make it neater easily.

To protect yourself from the flaw, you can use another search engine, or ensure you only use google from www.google.com - ensuring there’s nothing in the query string before you do a search, or disable javascript. I’d also recommend uninstalling Google Desktop, the Google toolbar, and any other google product simply because well over 2 years to fix a trivial security issue that should never made it past the most basic QA from the most inexperienced javascript tester suggests a serious problem with understanding the basics of security.