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:
- NO XSS IS REQUIRED!
- Create a Google Docs Account and upload a properly formatted Crossdomain.xml file
- Once the file is uploaded, you publish the file, exposing the file to every authenticated Google.com user.
- Create a flash object on a malicious server, pointing the System.security.loadPolicyFile() to the document that you uploaded to Google Docs.
- 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?).
- 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.
nice hack!!!
ReplyDeletebtw, we will see more of these in the future since the web becomes more and more open to user submitted content. On another note, the W3C people are thinking of implementing the crossdomain.xml concept for browser JS as well. To me, this is just plain bad idea!!!
ReplyDelete"On another note, the W3C people are thinking of implementing the crossdomain.xml concept for browser JS as well. To me, this is just plain bad idea!!!"
ReplyDeleteSweet Jesus - nooo... I didn't know that but dreamt about it.
Nice find Billy AND/OR Nate!
Has this been fixed? The PoC does not work for me (tested on Firefox and Safari)
ReplyDelete@MartinJ - Still works for me at this time. I haven't tested it with Safari, but it should still work as I'm obeying all of Flash's cross domain rules. It seems that pulling cross domain content with a Flash Object loaded by Firefox is a little buggy. Some instances of Firefox require a refresh in order for the list to appear (which I built into the page). Is the page refreshing after 10 seconds in your browser?
ReplyDeleteBK
The day that the implement crossdomain.xml in JavaScript will be a very very sad day... at least right now I can install a browser that doesn't support flash... I mean, the whole web requires JS.
ReplyDeleteSad September for Google Security team...
ReplyDeleteLooking at your PoC I've noticed that a more simple CSRF can be used to steal contacts as the remote resourse is not token-protected:
http://docs.google.com/contacts/data/contacts?thumb=true&groups=true&show=ALL&enums=true&psort=Name&max=900
(e.g using )
More, Adobe livedoc states that loading the crossdomain file from docs.google.com your application can access "only" to that domain...how can you access resource from mail.google.com domain? Is it the missing step? :-)
@Rosario - Ahhh... if only it were so easy. Causing the browser to display sensitive content and pulling that sensitive content to an attacker controlled domain are two totally different things my friend.
ReplyDeleteThe second item is left as an exercise for the reader,but all the heavy lifting is already done for you...
Nice post xssniper. Quite an eyeopener. I'm a firm believer in the SAAS model and I've just started using Googledocs at our company. I'll be folowing this with special interest. Anyone know if these issues also known to effect the MS Office Live env or does MS do it different?
ReplyDelete[...] of the more interesting attacks pulled off on Google applications, see Billy Rios and my previous work on Google Docs, get’s only as much coverage as the security researcher who did or did not disclose the [...]
ReplyDelete[...] commented on the article, mentioning several past vulnerabilities: ownership of content issues, Google Docs theft, a cross-domain hole, Google XSS, and a Google Picasa protocol handler issue leading to [...]
ReplyDelete[...] commented on the article, mentioning several past vulnerabilities: ownership of content issues, Google Docs theft, a cross-domain hole, Google XSS, and a Google Picasa protocol handler issue leading to [...]
ReplyDelete