Google Desktop - The Saga Continues
It suddenly hit me this morning. Google’s entire security model is based on not finding a single XSS hole in Google’s domain. The amazingly poorly thought out link between Google desktop and Google’s website creates one of the worst security holes I’ve seen. After reading Watchfire’s paper on “Overtaking Google Desktop” yesterday I too took a look at Google Desktop. For those of you who aren’t aware of how it works, it basically looks for certain strings in the Google domain and replaces them with a link to itself. It does this using a browser shim (not a network shim). This simple design decision is one of the few things that’s saving them from having a second vulnerability right now.
The link itself is to Google Desktop and it includes a nonce (a one time token). That one time token is the second reason that Google Desktop is briefly saved from exploitation. This one actually is a good design decision (not the integration with the website, but forcing the nonce to be there and validating it on each request). The nonce changes with each request, so knowing it once doesn’t mean knowing it for other requests. However, here is where things start falling apart pretty quickly.
Google Desktop is pretty much completely susceptible to a mixture of Anti-DNS pinning and header forging (also known as anti-anti-anti DNS Pinning) (and even that is only to make sure the Host: header reads “127.0.0.1:4664″). Okay, but what about the nonce? Doesn’t that make Google’s Desktop super uber secure? Hardly. Now all we need to do is find one XSS hole in allllll of Google where Google’s Desktop reads the header and overwrites it with its nonce. The XSS hole reads the nonce, pops an iframe with the data needed for the anti-DNS pinning, spoofs the header and voila, read/write access to Google Desktop.
You are may now be asking, “But if you have an XSS hole on Google there is a lot of other things you can do.” Maybe, but remember, Gmail is on another cname (mail.google.com). So if you can’t read their gmail, why not just read the files from their cache instead (which Google happily keeps for you)? Normally cache would be unavailable to your browser, but luckily for the attacker Google’s Desktop makes that matter rather trivial. “But that seems like a lot of work. I mean, why tip your hand if you aren’t even sure if they have Google Desktop installed?” Oh, I don’t know, why don’t we just detect if they have it installed just to save us some hassle? So I wrote a little detection mechanism to pull an image from Google Desktop (I guess the Google engineers got lazy and decided not to add nonces to their images). If it’s there, they have it installed and turned on, if not, don’t bother running your exploit.
Again, the heavy integration between web based and client based software is not a good thing. There are far too many unknowns and far too many holes out there right now. Just ask yourself this. If the security of every file on your computer rested in the hands of Google’s engineers never inadvertently creating a single input validation hole would that make you very comfortable knowing their history (1, 2, 3, 4, 5)?
February 22nd, 2007 at 11:04 am
Your right the injection seems to be happening on the browser level, not the network.
The link shows up in IE, firefox, and opera when the desktop is running, but not in more obscure browsers like amaya or through wget.
Does anyone have more information about what exactly browser shims are? And how the heck do you disable them?
February 22nd, 2007 at 11:08 am
[…] Since I didn’t have Google Desktop installed, I figured I’d give it a shot. It all seemed a little too Orwellian for me. Then after reading Rsnakes last two posts about a single xss hole in Google allowing an intrusion vector into your PC, it felt time to turn the thing off. Now all we need to do is find one XSS hole in allllll of Google where Google’s Desktop reads the header and overwrites it with it’s nonce. The XSS hole reads the nonce, pops an iframe with the data needed for the anti-DNS pinning, spoofs the header and voila, read/write access to Google Desktop. […]
February 22nd, 2007 at 11:23 am
Sometimes, it can interchange www.google.com with mail.google.com. e.g. www.google.com/webhp and mail.google.com/webhp, www.google.com/nwshp and mail.google.com/nwshp, etc. So, I think if you have an XSS hole on google.com, you can read their gmail if it can replace the subdomain by “mail”.
February 22nd, 2007 at 11:27 am
Few days ago there was also another XSS in google, I posted it in the Full Disclosure:
http://sla.ckers.org/forum/read.php?3,44,page=40#msg-7126
February 22nd, 2007 at 11:40 am
@Hong - even better… that widens the places to look for more XSS as well. Extremely insecure design. Clearly I don’t go to Google enough, I should have known that.
@nEUrOO - of course you did. There’s been hundreds, those are just the few I wrote about. I was sorta being facetious. They are terribly insecure.
February 22nd, 2007 at 12:30 pm
Actually, Google Desktop does not uses one-time tokens. Every user has a specific key (found in the registry at HKCU\Software\Google\Google Desktop\fuse_data) that is used to generate a signature for each URL request. As the search form uses GET, every query would have a different signature. However, the home page and the search form have specific signatures that do not change and can be found in the registry at HKCU\Software\Google\Custom Search\Google Desktop Search named Site and Url respectively. These are the links that are injected via the browser shim into the Google site. If I can capture that signature once, it’s all I need …
Signatures are a good protection mechanism against XSS and XSRF, but the link from the public web server to the local web server creates the window of opportunity.
February 22nd, 2007 at 2:31 pm
@Danny - yes, that’s what I meant (may have phrased it wrong). But for all intents and purposes it is unique per page making it one time. If you can fix another way to pull reg keys from the system that would be a whole different sort of vulnerability.
February 22nd, 2007 at 4:10 pm
Did any of you guys also get the Watchfire ‘warnig email’ - if yes I don’t have to say anything more
February 22nd, 2007 at 4:47 pm
No, I didn’t see that. Was it a typo or was there something else?
February 23rd, 2007 at 1:21 am
I don’t remember i ever have installed google desktop, and http://ha.ckers.org/weird/google-desktop.html says it’s not running.
But what bothers me is this.
******************************************************
Snippet form Firefox plugin ‘Live HTTP Headers’
******************************************************
http://toolbarqueries.google.com/search?client=navclient-auto&ch=6731864913&features=Rank&q=info:ha.ckers.org/&num=100&filter=0
GET /search?client=navclient-auto&ch=6731864913&features=Rank&q=info:ha.ckers.org/&num=100&filter=0 HTTP/1.1
Host: toolbarqueries.google.com
User-Agent: Mozilla/4.0 (compatible; GoogleToolbar 2.0.114-big; Windows XP 5.1)
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: nl,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: PREF=ID=84212c20d5fa10ee:TM=1170597104:LM=1170597104:S=9SeApMq2DJkzxetX
HTTP/1.x 200 OK
Cache-Control: private
Content-Type: text/html
Server: GWS/2.1
Transfer-Encoding: chunked
Date: Fri, 23 Feb 2007 08:18:14 GMT
*****************************************************************
I requested http://ha.ckers.org/ , and with all the normal headers coming along, there always seems to be al request to /toolbarqueries.google.com/ ? And i dunno why!!??
February 23rd, 2007 at 5:05 am
[…] Für alle Fans vom Google Desktop hat RSnake da ein paar ganz schöne Dinge zusammengeschrieben. Irgendwie beängstigend. […]
February 23rd, 2007 at 10:53 am
@fré - what you have uncovered is Google’s spyware. I believe that is if you have the search toolbar plugin installed. You can also see similar requests if you have their web accelerator installed. Those are unrelated to this attack, but they definitely are stealing your information. Yay for spyware!
February 25th, 2007 at 11:39 am
This is basically a rehash of an attack againt Google Desktop that I demonstrated more than a year ago:
http://www.hacker.co.il/security/ie/css_import.html
The Watchfire paper describes and uses the technique I showed in my proof of concept to gain access to the local GDS web server.
The only thing that changed is the vector for bypassing the same origin policy. They also added a sticky XSS vulnerability which is a nice touch.
Matan
February 25th, 2007 at 4:52 pm
When you say “this” I assume you are referring to the Watchfire issue and not the anti-anti-anti DNS Pinning issue I’m talking about (which requires no XSS on the desktop itself at all to work).
March 7th, 2007 at 9:02 am
This has hit the Wall Street Journal (sorry, need a login for access - you can try bugmenot): http://online.wsj.com/article/SB117313867582027623.html
March 15th, 2007 at 11:53 am
SO…
being new to this stuff, here’s the question…
If I don’t use google desktop, should I be scared of the issues raised here?
thx.
March 15th, 2007 at 1:05 pm
If you don’t use Google desktop you would not be vulnerable to the google desktop issue. You may be vulnerable to other issues - I can’t comment there, but not of this particular issue no.
March 18th, 2007 at 9:42 am
RSnake, not sure you have seen this blog entry: http://www.squarefree.com/2004/10/22/my-impressions-of-google-desktop-search/
Note the date. I guess “Show Desktop Search results on Google Web Search result pages” option is no more?
March 21st, 2007 at 9:23 am
[…] has been widely written about; the idea is that if a web site will display unescaped user-submitted data then this […]
March 23rd, 2007 at 8:46 pm
[…] over at ha.ckers shows early signs that additional Google Desktop attacks are in the […]
March 23rd, 2007 at 11:17 pm
A good writeup on how to disable the link between Google’s website and Google Desktop. While I’m not 100% certain this is all it takes to shut off this vector, it definitely would require re-thinking the flow, considerably: http://hackingspirits.com/vuln-rnd/vuln-rnd.html