There's an OAK TREE in my blog!?!?!

A while back I came across another interesting issue that allowed me to steal an arbitrary Google Doc (assuming I knew the DocID). This issue has already been fixed by Google, but the details are pretty interesting so I thought I would share! Now, before I get into the gory details, I'd like to mention two things about Google:

 



1. I know some people have had issues with Google's Security Team (GST), but I've always had pleasant experiences with them. GST moves with LIGHTING speed and they are usually great about keeping in me apprised of the status of various issues I've reported to them.

 



2. In addition to fixing this particular exposure, GST has also increased the entropy of the DocID making sploits based on DocID guessing totally impractical. It's a great example of going the extra step to help protect users...

 

Now... the gory details... First, I went to Wordpress.com and created a new blog (there were other ways to pull this off, but this was the easiest way). Once the blog was created, I logged into Google Docs with my account, created a document and selected the "publish this document" option. Once in the "publish" menu, I selected the "Blog Site Settings" option. This option basically allows a Google Docs user to create a document in Google Docs and POST it directly to thier blog! I entered my blog provider, blog username, and blog password into the blog settings page. The page is shown below:

 

 

Once my blog settings were properly entered, I selected the "Publish This Document To Your Blog" option. The POST request made by my browser looked something like this:

 

POST /MiscCommands HTTP/1.1
<HTTP HEADERS>

command=cmdvalue&localDate=datevalue&docID=doc-id-here&finis=finisvalue&POST_TOKEN=posttokenvalue

 

When this feature is selected, it appears that the Google Docs server makes a request to the xmlrpc.php file on the blog server (Wordpress.com), passing the credentials I gave in the blog settings. When the blog server indicates that the blog creds were valid, the Google Docs server sends the contents of the Google Doc to the blog server. hmmmm... that docID value looks reeeallly interesting... I changed the docID in the POST request from the docID of my newly created document to the docID of the "Article For Oak Tree View" (the document used by Google to Demo Google Docs).

 

 

After changing the docID and sending the POST request, I logged into my Wordpress Blog and LO AND BEHOLD... my first blog POST was the Oak Tree Newsletter!

 

 

I tried it on some friends documents with the same result and then contacted the GST....

 

Links to other Google Docs Stuff here, here, and here

All Your Google Docs are Belong To US...

It's been a rough week for Google Security...  It seems like everyone had some Google vulnerability they wanted to disclose this week.  You can see some of the various vulns here, here, and here.

   

Well... the week isn't over YET!  I'm actually disclosing this vulnerability because Google has already fixed it.  Although I don't use Google Docs (because I'm a paranoid guy), I know a lot of people who do and I didn't want to put their docs at risk.  Without  further delay, the details...
 
This vulnerability allowed any Google Docs user to STEAL ARBITRARY DOCUMENTS from the Google Docs Server.  The basis of the vulnerability stems from a simple Session Management issue.  Once a user has logged into Google Docs and has created a document, they are presented with several options.  Under the "Share" tab, the user has an option to "Email Collaborators"

     



   

Once the user clicks the "Email Collaborators" link, the following HTTP GET request is made to docs.google.com:

   

GET /Dialogs/EmailDocument?DocID=<ANY DOC ID HERE> HTTP/1.1
<appropriate HTTP headers here>

    

If you changed the DocID value to another DocID, Google Docs WOULD NOT VALIDATE whether you should have access to that DocID.  The title of the stolen document you requested will be shown (as a javascript variable) in the HTTP 200 OK response that is returned.  Once this step is completed, you can make a POST request to a Google Docs Server Side Script named MiscCommands.  The POST request looks something like this:

   

POST /MiscCommands HTTP/1.1
<appropriate HTTP headers here>
 
command=validate_address&docid=<ANY DOCID HERE>&addr=gmail%40gmail.com&finis=true&POST_TOKEN=POSTTOKENVALUE
    

If you changed the DocID in the POST request, the entire contents of that document would be emailed to the addresses specified in the "addr" parameter!  I tested this against several friends Google Docs and it worked EVERYTIME! 

   

This issue does stem on being able to predict the DocID for the document that you want to steal.  At first glance, the DocID seems to be a fairly stout "random string", but a little bit of analysis shows some interesting characteristics.  It seems that the DocID is delimited by an “_” character.  The characters preceding the underscore represent the Google Docs UserID.  Each document uploaded to Google Docs by a particular user will have the same characters up to the underscore.  Now... what about the characters after the underscore?  Well... take a look at what happens when I generate 10 different DocIDs in rapid succession:

    

mydocsid_14ggbd48
mydocsid_15gt54pt
mydocsid_16c44jws
mydocsid_17cnnfw8
mydocsid_18ggzpm7
mydocsid_19dczf6g
mydocsid_20c8h7nx
mydocsid_21czqc3h
mydocsid_22d48w8j
mydocsid_23f4hk9b
mydocsid_24gdwfzk

   

Maybe the last set of characters isn’t as “random” as we thought……  Throw in some DocID enumeration (which exists) and we may be on to something here…       I’ve seen Session Management issues like this in MANY of the web applications I’ve assessed.  If your hired gun (webapp pentester) looks at you funny when you ask if they are testing for Session Management issues, FIND A NEW ONE!  There isn’t a web app vulnerability scanner on the market that can detect this and Web App firewalls will not prevent this either!  It takes an actual brain and some experience to find these types of issues!                 
       
In closing, I would like to give a shout to the Google Security Team.  If you’ve ever dealt with the Google Security Team, you know that they take security seriously and they move fast…. VERY FAST.  After giving them the details for a couple of Google vulnerabilities, it took Google ONE DAY to fix the issues and to deploy the fixes worldwide… Kudos to Chris and the GST.

Google Docs puts Google Users at Risk

The whole concept of "Taking Ownership" of someone else's content can be VERY dangerous.  The reason taking ownership of content is so scary is because the ENTIRE trust model for the World Wide Web is basically built on ONE thing... the DOMAIN NAME.

   

This is why issues like XSS on sites like google.com are such a big deal... XSS basically allows an attacker to execute client side code in the context of the vulnerable domain.  Malicious client side script is one thing... but malicious client side script executed in the context of a trusted domain is something entirely different... but I digress...

   

Google Documents basically allows you to upload your documents (aka content) to a Google server.  Once you've uploaded the document, Google has essentially "taken ownership" of the document (content).  There are ways to minimize the risks associated with taking ownership of content and it seems that Google has taken some measures to sanitize for XSS... but it seems that their focus on XSS may have caused them to miss a different type of cross domain exposure.

   

Flash Players (>7.0.19.0) support a new method for making cross domain requests.  This method allows a user (or attacker) to specify where a crossdomain.xml file is located on a particular server.  Essentially, if the flash player finds this crossdomain file (and the file is properly formatted) the flash player will allow cross domain requests to the domain that "owns" the crossdomain policy file, in this case... Google.com.   We talked about issues like this at our DEFCON talk.... but I guess Google missed out.

   

So, the Proof of Concept works like this:

1. NO XSS IS REQUIRED!


2. Create a Google Docs Account and upload a properly formatted Crossdomain.xml file


3. Once the file is uploaded, you publish the file, exposing the file to every authenticated Google.com user.


4. Create a flash object on a malicious server, pointing the System.security.loadPolicyFile() to the document that you uploaded to Google Docs.


5. Once the Flash object has read the contents of the crossdomain file from the Google server, it assumes that Google has allowed cross domain requests (I mean… who in their right mind would allow random people to upload random files to thier server and serve that content under the context of their trusted domain name?).


6. Now, the flash object has full access to the google.com domain and can steal all your Google information.

   

Proof of Concept can be found here.  The PoC just displays your contact list, but I have full access to the Google.com domain, so the sky is the limit (aka I can read all your email too)... I left out one key step needed to pull this off and the source for the Flash applet will not be published at this time in order to slow the kiddies. 

     

If anyone from Google Security comes across this page, send me an email and we can go over the missing step as well as the Flash Source... I'd also like to talk to you about another hole in Google Docs that allows me to ACCESS ANY ARBITRARY USERS DOCUMENTS.