Following the Skype security hole brouhaha, we have been pointed to a cross site scripting (XSS) vulnerability in GoogleUserContent.com that allows an attacker to create a phishing scam which is hosted on Google.com. In other words, victims could potentially be tricked into entering their Google account details (whether for Gmail, Google+, or for another Google service) as they think they are on Google.com.
According to The Hacker News, the story behind this one goes a little something like this. Two months ago, Indian hacker Mohit Kumar discovered the XSS vulnerability on Google’s domain, and wrote up a proof of concept.
F**k it, we'll do it live!
Our biggest ever edition of TNW Conference is fast approaching! Join 10,000 tech leaders this May in Amsterdam.
Kumar then submitted it to Google on September 11. Two days later, he received this response:
In other words, Google wasn’t bothered by the issue and thus didn’t grant Kumar a bug bounty prize. Kumar figured this wasn’t too big of a deal, since Google informed him it was not exploitable and was further on a sandboxed domain. Nevertheless, after all this time, he was surprised to learn that the issue still hasn’t been fixed.
To make matters worse, yesterday another Bulgarian hacker going by the name “Keeper” informed him that the vulnerability is still working even after multiple submissions to Google. Keeper thus successfully exploited the Google vulnerability which was ignored by the company and, under Kumar’s instructions, created a phishing page using the persistent XSS flaw “so that we can show a demo to world that, cross site scripting is not only a minor bug, if creatively exploited,” according to Kumar.
Here’s how it looks (we are not linking to it, and of course blocking out the URL in the screenshot as we do not want readers inadvertently trying it out and submitting their details to Keeper):
This is just a proof of concept, but it gets the point across. This looks like a legitimate Google login page hosted on Google.com, but it really could be a phishing site that would steal your login credentials if you enter your account details (we’ve checked, and yes, it works).
We have contacted Google about this issue. We will update you if and when we hear back.
Update: Google explains that this is not a vulnerability after all. The company’s statement is as follows:
Using iGoogle, or any Google product, to serve deceptive content is a violation of our product policies. We will remove offending content from our gadget gallery. For more information about our security approach to hosting content, you can read more here: http://googleonlinesecurity.blogspot.com/2012/08/content-hosting-for-modern-web.html.
Here’s the relevant part from that link:
In the end, we reacted to this raft of content hosting problems by placing some of the high-risk content in separate, isolated web origins—most commonly *.googleusercontent.com. There, the “sandboxed” files pose virtually no threat to the applications themselves, or to google.com authentication cookies. For public content, that’s all we need: we may use random or user-specific subdomains, depending on the degree of isolation required between unrelated documents, but otherwise the solution just works.
The situation gets more interesting for non-public documents, however. Copying users’ normal authentication cookies to the “sandbox” domain would defeat the purpose. The natural alternative is to move the secret token used to confer access rights from the Cookie header to a value embedded in the URL, and make the token unique to every document instead of keeping it global.
In short, this is simply a violation of Google’s policies. Still a bit worrying though, as the Google.com domain name can be very easily abused here.
Image credit: J V