6/11/2012

Cross-Site-Scripting in Google Mail

In the last months I found several XSS vulnerabilities in Google's Gmail. All bugs are now fixed in a very short time. Currently Gmail has around 350 Mio. users and it's clear that Google taking a lot of efforts to protect their users. (Safebrowsing, Google's Security Tools, 2-Step-Verification, Vulnerability Reward Program, warnings for suspected state-sponsored attacks, Browser Security Handbook, Webmaster Tools warnings for hackable sites, Google+ with CSP evaluation and much more).

Google shared some stats about the VRP last year and told that around 65% of all reported bugs are XSS.

Google VRP stats
global VRP stats

And that statistics are completely true. Here my stats made with around 220 bugs:
my VRP stats (222 bugs)

So the numbers are nearly the same and I think every other company who develop web application has the same bug distribution and a much higher amount of bugs. Google has made a great job and compared with the amount of new features and new products, the relative frequency of security bugs is quite low.


Today I want to share 3 different XSS vulnerabilties in Google Gmail.

1. Persistent DOM XSS (innerHTML) in Gmail's mobile view

A incoming mail containing <img src=x onerror=prompt(1)> within the subject and forwarded to another user, has lead to XSS.

That's a funny bug, because something went wrong while some engineers was working on a fix. For some hours every fowarded message contain "// The body is already esacped"Oops!

2. Reflective DOM XSS in Gmail's mobile view

https://mail.google.com/mail/mu/#cv/search/%22%3E%3Cimg%20src%3Dx%20onerror%3Dalert(2)%3E/foobar

That's all. Just a simple reflective XSS in the search feature for labels. 

3. Persistent XSS in Gmail

There are two ways to display a message directly:

https://mail.google.com/mail/u/0/?ui=2&ik=293aded8ef&view=om&th=237da8dbcf05dac2
https://mail.google.com/mail/u/0/?ui=2&ik=293aded8ef&view=domraw&th=237da8dbcf05dac2
  • ik = it's a static ID for that particular user 
  • view = representing the current view of Gmail
  • th = message id
The response of both requests is text/plain.

With a special crafted URL it was possible to force a "HTTP/1.1 500 Internal Server Error" with some lines of the message. The Content-Type is now: text/html.




But we still have a problem. An attacker doesn't know the ik and the message id. Without both values it's not possible to generate the special URL.

But it's easy to get both values through referer leaking. 

We have to send to our victim a HTML e-mail with that content:

<a href="https://attackershost.com/gmailxss">Click here to have fun</a>

<script>alert(/xss/)</script>

  • The 1x1.gif leakes the ik and the message id to attackershost.com (images are loaded in print preview and if the sender is a trusted mail source)
  • the link to attackershost.com/gmailxss has the same effect, leakes the referer by click
  • and a javscript alert(/xss/) to demonstrate that's possible to run javascript in context of mail.google.com



The Google Security Team took immediately actions and blocked the particular GET parameter on their frontends as intermediate fix with the message: 

"We're sorry ... but your computer or network may be sending automated queries. To protect our users, we can't process your request right now."




If you wanna read more about Google's VRP I recommend you the talk of Nir Goldshlager "Killing a bug bounty program" or you can just read some of my older posts here, here, here and here.

Any questions? Use the comments below the post.

PS: Enable 2-step-verification for your Google account today to make your Gmail more secure.