Google Analytics XSS Vulnerability

This post documents an XSS vulnerability I discovered in the event tracking functionality provided by Google Analytics. Given a website's Google account number (which can be found in the site source), one could spoof specially crafted events that, when clicked in the administrative interface, would run arbitrary Javascript in the victim's browser. This would allow an attacker to, among other things, hijack the account. Although it did not affect as many users as the Gmail XSS vulnerability did, it posed a significant risk to many site administrators, who are prime targets for attack.


Vulnerability Discovery

Back when I released d0z.me, I realized that I had never set up event tracking for tarball downloads on my site. While getting this configured, I got curious as to how well Google sanitized the incoming data, given that a malicious user could arbitrarily define what events would be sent and then presented to an administrator. I wrote up some incredibly simple Javascript that would send an XSS testing string in the various fields provided by the event tracking API. After waiting a few minutes for it to update in the Analytics interface, I inspected the results.

Sure enough, while double quotes and tag characters were escaped in the corresponding link, single quotes were not. This would have been OK (the rest of their js code uses double quotes religiously for strings), but their use of Javascript link handlers and the need to pass an array of strings made the problem exploitable:
Good :

href="event_object_detail?id=XXXXXXX&pdr=XXXXX-XXXX" onclick="whatever_needs_doing()"

Bad :

href="javascript:analytics.PropertyManager._getInstance()._broadcastChange('events_bar_detail', ['type', 'location'+alert('xss')+'', 'event_action'])"

Interestingly, the Top Events section of the Event Handling page seems to be the only place in the Analytics admin interface where Javascript is called like this, which might have been part of the reason the vulnerability existed. It also did not overtly break the page, which might have kept testers from noticing. Getting into the Top Events section is trivial, as one only has to loop the Javascript as much as desired.
In Action :

Note that the malicious nature of the link is only obvious for demonstration reasons. Simply putting a legitimate URL in front of the malicious payload would hide it from the user.


Disclosure

I contacted Google regarding the vulnerability on January 5th, with relevant PoC code. They replied on the 6th, confirming the vulnerability, and confirmed that a patch had been written and was being tested on the 12th. On February 3rd, they confirmed their testing was complete, and that the patch was in place. I confirmed with my own tests, and then publicly disclosed. In addition, I was awarded $1000 for the report. Not bad for a little bit of Javascript and poking around. :P

Unrelated Blather

To those wondering where I've been the past month or so, I have been busy IRL getting set up at grad school among many things. As this blog is mainly to document the research and such that I am doing, the amount I post is directly related to the time I have to mess with things. I promise, updates to d0z.me soon, as well as my first Android vulnerability (yay!), and then whatever I feel like posting on after that. It's good to be back!