Today RSnake revealed a cross site scripting vulnerability affecting Google Gadgets in the gmodules.com domain.
This XSS hole allows anybody to store his/her own web content, including JavaScript code, anywhere and to have it rendered and executed in the context of the gmodules.com domain, with no further validation of sort.
RSnake responsibly reported his finding to Google before resorting to public disclosure, but the G guys answered that this behavior is “by design” and won’t be fixed.

What does it mean?

For the average user, such a vulnerability means that phishers can effectively exploit a site owned by Google as a free hosting facility, making quite impractical blacklisting and/or shutting down the scam: don’t forget Firefox’s built-in anti-phishing blacklist is provided by Google itself.

For NoScript users, it means that if you allow gmodules.com to execute scripts, you’re trusting not just Google, as you may misled to believe, but everyone in the cyberworld — even the most evil hackers like my RSnake friend ;) — to run his/her code inside your browser.

The bottom line is: until Google security crew changes its mind and decides to rethink or remove this “feature”, do not whitelist gmodules.com — even better, mark gmodules.com as untrusted.
If you absolutely need scripts from the gmodules.com domain, e.g. to use those so called mapplets (another nifty Web 2.0 marvel), just “Temporarily allow” it and cross your fingers.

On a side note, U.N. site is still vulnerable to defacement

11 Responses to “Don’t Trust Google’s XSSploding Gadgets”

  1. #1 xvcefj says:

    gmodules.com resolves to google.com
    how then do we mark gmodules as a NoScript untrusted site without having to do the same to the entire google domain?

    ty

  2. #2 Giorgio says:

    @xvcefj :
    gmodules.com and google.com, even being both Google domains and resolving to the same pool of hosts, do serve different content and deserve different levels of trust.
    While gmodules.com serves user-generated content including scripts from perfect strangers, www.google.com serves (or should serve, pending other XSS vulnerabilities) only scripts from Google.

  3. #3 Aerik says:

    @xvcefj :

    Go to about:config, enter noscript.untrusted and add gmodules.com to the end of it yourself.

  4. #4 sirdarckcat says:

    The following sites use GModules.com scripts:

    -> Google Pages (http://pages.google.com/)
    -> Google Desktop (http://desktop.google.com/)
    -> iGoogle (http://www.google.com/ig)

    Any way, is there any solution (from the Google side) for this?
    I mean, I can’t think a way Google can enable users to create their own modules if it’s not this way..

    I think that as a “Phishing” attack, there’s a more dangerous vector using googlegroups.com, googlecode.com, googlepages.com, domains..

    Any way, this “feature” can work extremely easy as a “defacement” attack against iGoogle, or Google Pages, and as a DoS to the SO, if you use Google Desktop.

    So..
    1.- Don’t use gadgets with Google desktop.
    2.- Don’t use gadgets with Google pages.
    3.- Don’t use gadgets with iGoogle.
    4.- Don’t use gadgets at all :P

    The second and third point can be avoided using NoScript, but the first one.. well.. Google Desktop is just evil.

    Greetz!!

  5. #5 Tyokm says:

    Lamest. Hack. Ever.

    Maybe they’re hosting it on a separate domain so that there is nothing to xss? Thats how browsers work dumbass, all web security is domain based. If I host my website ffdsokjfsld.com on the same host as you, I can put javascript on there. does that mean hackademix.net is vulnerable to xss? no. because that would be stupid.

  6. #6 ·¨-=[WHK]=-¨· » Archive » Los “gadgets” de Google como herramienta de “phishing” says:

    […] Don’t Trust Google’s XSSploding Gadgets [Giorgio Maone]. […]

  7. #7 Giorgio says:

    @Tyokm:
    This is XSS, because everybody (nice guys and evil criminals) can put their scripts in the very same domain with no check.
    Moreover, they can change those scripts at any time, because they’re served from their own sites but rendered in the gmodules.com context.

    As you said, all web security domain based.
    This means that I can decide to trust mozilla.org because I know they wouldn’t do me any harm (or at least, they could do much more harm with their browser than their site) and decide I don’t trust some b3stw4r3z.ru website because l33t sp33ch gives me severe headaches.
    This is especially true for NoScript users, who don’t want to execute a script unless they trust (or believe they can trust) its origin.

    What should I do with gmodules.com then?
    When you’ve got to decide if trusting a certain group of principals or not, the criterion must be “the group can be trusted as much as its least trustworthy member”.
    Since gmodules.com as a domain can deliver scripts from any party, even the evilest, nobody in its mind could ever trust it at all.

    Even blogspot.com offers a different domain for each publisher, so I can choose to trust sirdarkcat.blogspot.com and distrust kuza55.blogspot.com (or the way around), though they’re probably hosted on the same physical facility and definitely by the same service provider. Not a perfect solution, since to many users www.blogspot.com and www1.blogspot.com are the same site, but better than nothing.

    So, coming to sirdarckcat’s question, “is there any solution (from the Google side) for this?
    My answer is yes.
    Other than providing an unique subdomain for each widget/module publisher (a la blogspot), which is probably quite inconvenient and not necessarily effective for the average user (see above), Google could:

    1. Let publishers serve their widgets from their own hosting places (e.g. churchwidgets.com or flyingspaghettimodules.ru)
    2. Provide publishers with a bootstrap API to be included his/her own domain, transforming the XML widget definition into HTML content when it’s served.
    3. Provide consumers (i.e. the sites which will embed the widgets/modules) with a script that creates the iframe and loads it with the widget’s bootstrap script from its hosting location (much like AdSense works).

    The “one domain/one trust choice” principle would be honored: I can decide to distrust churchwidgets.com and welcome flyingspaghettimodules.ru ;)
    The only downside, other than a slightly more complex setup, is that “XSS by design” (i.e. different modules from different parties interacting — or better said, hacking each other — as they were the same application, inside the same domain) wouldn’t obviously work, but this would be easily overcome if widgets wanting to be “mashed up” provide a JavaScript API to be included with a

    <script>

    tag, which is however the cleanest way to do that.

  8. #8 Matt says:

    Actually, Google does provide a unique subdomain for many, if not all, of the modules. When I opened up Noscript while on iGoogle, I saw a lot of “19.gmodules.com”, “42.gmodules.com”, etc.

    Not overly helpful- I have no idea which module is coming from “20.gmodules.com”, and it would take a lot more trial and error than I have patience for to figure it out.

  9. #9 Giorgio says:

    @Matt:
    thanks for the info, but as you said it doesn’t help because you cannot reliable associate a trust principal with the domain name yet.
    And we can easily modify RSnake’s original PoC to demonstrate how we can inject our code in the 2nd level domain and in any of these pseudo-subdomains:

  10. #10 Los “gadgets” de Google como herramienta de “phishing” « says:

    […] Don’t Trust Google’s XSSploding Gadgets [Giorgio Maone]. […]

  11. #11 Shadow Security Blog » Blog Archive » Los “gadgets” de Google como herramienta de “phishing” says:

    […] Don’t Trust Google’s XSSploding Gadgets [Giorgio Maone]. […]

Bad Behavior has blocked 33436 access attempts in the last 7 days.