Taking ownership (pwnership) of content: Cross-site Scripting Google
My good friend Billy Rios (pictured to the right) published another interesting exploit recently. It's a cross-site scripting exposure in spreadsheets.
My good friend Billy Rios (pictured to the right) published another interesting exploit recently. It's a cross-site scripting exposure in spreadsheets.google.com, which is interesting because it's exploited by using the content-type returned by spreadsheets.google.com and a caching flaw on the part of Google. Here's some details from Billy's blog:
I was able to pull off a full blown XSS against the google.com domain. For those of you who don’t understand what this means, allow me to elaborate. When Google sets their cookie, it is valid for all of their sub domains. So, when you log into gmail (mail.google.com), your gmail cookie is actually valid for code.google.com, docs.google.com, spreadsheets.google.com…and so on. If someone (like me) finds an XSS vulnerability in any one of these sub domains, I’ll be able to hijack your session and access any google service as if I were you.
Rios has pointed out a good number of issues to Google's Security Team. One thing that seems consistent is that Google's apps are really all about features and interplay amongst each other. They really try to make the user experience as easy and capable as possible. Part of that involves shared cookies across their domains as Rios mentions. Part of that involves taking ownership of user supplied content. All of that leads to great apps, but difficult security challenges. Billy discusses the impact of this exploit on his blog, which I paraphrase below:
So, in this instance, I have an XSS on spreadsheets.google.com. With this single XSS, I can read your Gmail, backdoor your source code (code.google.com), steal all your Google Docs, and basically do whatever I want on Google as if I were you! Google’s use of “document.domain=” also make things a little easier to jump from one domain to the next, but that’s another story…
Yes, another story for another day, but for the researchers out their, Google's use of document.domain does raise some concerns. Billy details the vulnerability he discovered on his blog, which I paraphrase below:
This particular XSS takes advantage of how Internet Explorer determines the content type of the HTTP response being returned by the server. Most would think that explicitly setting the content-type to something that isn’t supposed to be rendered by the browser would easily solve this issue, but it does not. IE isn’t the only browser that will ignore the content-type header in certain circumstances, Firefox, Opera, and Safari will ignore the content-type header as well (in certain circumstances). Security professionals and more importantly developers need to understand the nuances of how the popular web browsers handle various content-type headers, otherwise they may put their web application at risk of XSS. The most comprehensive paper I’ve seen on the subject was written by Blake Frantz of Leviathan. The paper can be found here. It’s a “MUST HAVE” reference for web app security pros. Read it, understand it, protect yourself appropriately or expect others to exploit appropriately…
In this issue, Google set the content-type header for a response which I controlled the content to text/plain. If I can inject what looks like HTML into the first few bytes of the response, I’ll be able to “trick” Internet Explorer into rendering the content as HTML. Luckily for me, I was able to do just that.
I created a spreadsheet on spreadsheets.google.com and for the first cell (A1) I put the following content: “<HTML><body><script>alert(document.cookie)</script></body></HTML>”
I then saved the spreadsheet and generated a link for the spreadsheet to be served as a CSV.
When this option is selected, the contents of the spreadsheet are displayed inline (the content-disposition header was not explicitly set to “attachment”), IE ignores the content-type header, sniffs the content-type from the response, then proceeds to render the response as if it were HTML. At this point, I control the entire HTML being rendered under an xxx.google.com domain.
To be fair, Google included a subtle defense to protect against content-type sniffing (padding the response), but those protection measures failed (with a little prodding by me). The issue is fixed, but if you try to reproduce this issue, you’ll see their defense in play. It a solid defense which shows they understand the nuances of content-type sniffing.
I’ll provide some tips on taking ownership of untrusted content and serving it from your server in a later post, but for now take a look at the paper written by Blake Frantz. I’m sure it will open some eyes…
This is a very interesting attack vector, which is truly dangerous, and it's a good thing for Google users that the Google Security Team is quick to react to these types of issues.
Billy and I (along with Rob Carter and John Heasman) will be submitting a paper for Black Hat Vegas on the subject of taking ownership of user content, along with a myriad of other issues, including John Heasman's abuse of Java, Billy and John's discoveries with online word processing applications, and Rob and my work on locally running web servers and DNS rebinding. I know those sound like a lot of topics, but we've got some really nice tie ins, so hopefully we'll get accepted and you can see us there.
Also, it's not just about attacking all the time, which seems to normally be what I blog about, but I'll be catching up with Rios and possibly Blake Frantz this coming weekend at ToorCon, so I'll see if I can't get them to give us a nice posting on how to prevent issues related to taking ownership (pwnership) of content.
