14 January 2007
Details of Google's Latest Security Hole
http://blogoscoped.com/archive/2007-01-14-n21.html
I’ve now received confirmation from Google’s Security Team that the latest vulnerability Philipp posted about has been fixed. After carrying out some investigations of my own, I believe this is the case – so I’m going to share with you what the problem was and how I was able to exploit it. In doing so, I hope to educate other developers about the potential flaws that can occur in growingly complex web applications.
In summary, I was able to create a page that was hosted on a google.com domain, which is something that should never be allowed to happen. Because of this vulnerability, I was then able to use a simple bit of code to steal someone else’s Google cookie and access their Google services.
Background
Earlier this month, Google announced that Blogger Custom Domains would allow you to host your own blog on the Blogger platform using your own domain name rather than a blogspot.com address.
Here’s how it should work:
- Buy your domain name – e.g. example.com
- Create a CNAME record that points your domain or subdomain to ghs.google.com – e.g. blog.example.com (see these Blogger Help and Google Help entries for more information on DNS settings and creating CNAMEs)
- Setup your blog using a blogspot.com address (if you’ve not already got one) – e.g. example.blogspot.com
- Enter your domain name in Blogger’s Custom Domain publishing settings – e.g. blog.example.com
- Any requests to example.blogspot.com would be redirected to blog.example.com where your blog is now being hosted by Blogger
Soon after this feature was announced, I realized that you could enter any domain name in Blogger’s Custom Domain publishing settings regardless of whether you owned the domain or had setup a CNAME to point to ghs.google.com. Since Blogger claims that “you don’t have to pay extra for hosting service” and Google promotes private registration (meaning your details are withheld from a WHOIS lookup) there’s no reliable way to verify whether the Blogger user actually owns the domain they’re entering.
Under normal circumstances, this isn’t a problem; entering a domain that doesn’t have its CNAME setup to point it to ghs.google.com would simply result in any requests to the blogspot.com address being redirected to the domain. And this is actually useful for anyone with a blogspot.com address who wants to move their blog away from Blogger’s servers by using either FTP-publishing or another blog service altogether. (For example, ruscoe.blogspot.com now redirects to ruscoe.net which is hosted on my own server.)
This could only cause problems if you were to enter a domain name that already had a CNAME pointing to ghs.google.com (or another address that’s pointing to the same place). But what are the chances of being able to find a domain that’s already setup like that? Well... it was easier than you might think.
Proof of Concept Implementation
In the Google Blogoscoped Forum, Art-One had reported that he’d seen a Japanese blog being hosted at ghs.google.com (which is the same domain used by Custom Domains in Google Apps for Your Domain).
Whether this was done intentionally or completely by accident, someone had entered ghs.google.com as their Blogger Custom Domain. Since no blog was setup at this address, Blogger had allowed them to host their blog there. And that’s when the alarm bells started to ring. This would allow me to host my own content on the google.com domain too...
Since I keep a close eye on Google subdomains, I knew that ghs.google.com wasn’t the only google.com domain that pointed to that location and I immediately claimed ghs.l.google.com as my custom domain. (Google quite often has *.google.com subdomains setup as CNAMEs for their *.l.google.com equivalents.)
As any web developer will know, a page hosted at an address like ghs.l.google.com is perfectly capable of reading and writing google.com cookies, which meant that when Philipp visited my “proof of concept” page hosted on the ghs.l.google.com domain, I was able to “borrow” his google.com cookie data. This can be easily achieved using some simple JavaScript that would read the cookie and place the data into a hidden form field element. The form could then be automatically submitted to another server which would be hosting a server-side script capable of logging the form data to a database, text file or send it in an email.
Once the cookie data had been received, there are a number of methods which could be used to write data to a google.com cookie – meaning the hacker would be able to have the same google.com cookie data as you, giving them access to your Google Account and services.*
Problem Fixed
The Google Security Team was informed of the issue before I’d even written my proof of concept script to test on Philipp. Around three and a half hours later, Google had deleted my test page and were redirecting both ghs.google.com and ghs.l.google.com to Blogger’s standard “blog not found” page. (They’re now redirecting both addresses to the Google.com home page.)
Later that evening, I received this response:
Thank you for reporting this issue to us. We take the security of our users and their information very seriously. We wanted to let you know that we addressed this problem with expediency and have taken steps to ensure it cannot occur again.
It seems that Google followed my advice and fixed the problem by disallowing any Google domains to be entered as a Blogger Custom Domain. Trying to enter a Google domain in this field will return an error stating, “Another blog is already hosted at this address.” (Theoretically, this is overkill because the domain would also need to be pointing at ghs.google.com – but it’s always better to be safe than sorry!)
Avoiding Vulnerabilities
There are a number of ways to make sure you – as a user – don’t get caught by a security loophole like this. Some people would say you should only visit pages you trust – but who doesn’t trust a page on the Google.com domain? Others might say the answer is to disable JavaScript in your browser – but then you wouldn’t be able to use websites and applications that rely on JavaScript being enabled. You could also turn off or clear your cookies – but that could prevent many services that require a login from working. In this case, my proof of concept script would have failed if the user had either signed out of their Google Account, cleared their cookies or disabled JavaScript before visiting my page. But would you be prepared to do that before visiting any website you didn’t know was 100% safe? Of course, I could have just put up an official-looking page that was hosted on a Google domain showing a Google Account login box asking for a username and password – and who wouldn’t enter their Google Account details if they thought they were going to be one of the first to get a peek at a new Google service?
How can companies like Google prevent this from happening when developing new applications or features? I guess the most important rule is to make sure nobody can host or inject content (and particularly scripts) on your primary domain or a subdomain of your primary domain. This isn’t the first time that Google allowed this to happen. Just a few months ago, a user realized the Google Public Service Search could be exploited in a similar way, demonstrated with his Gmail Plus phishing page. This time it was a very special case though. Who would have thought that someone would find a google.com domain pointing to the right place and enter it as their custom domain? Some simple input validation would have allowed them to reject any requests for google.com domains to be used. But perhaps a more secure approach would have been to use a completely different domain in the first place – something like googleservicehosting.com, hostedbygoogle.com or googleafyd.com – all of which Google already own. It’s too late to change that now though, as thousands of users will already have pointed their domain to the ghs.google.com address.
Another way to prevent this from ever happening again would be to change how the same cookie is used to identify a user and give them access to many services. It seems odd that I could access Philipp’s Google Account at the same time as him from a completely different location, via a different IP address, using a different web browser with exactly the same cookie data. Admittedly, Google’s cookie is probably more secure than most – and I could no longer access his account when Philipp changed his password.
Finally, I think it’s worth pointing out that only a small number of people would have been able to exploit this security vulnerability because there are only a limited number of google.com domains which would have met the requirements – and once a domain is “claimed” it is unavailable for others use. Also, the Japanese blog didn’t contain any malicious script and my proof of concept page was only online for a few hours at an obscure address that was only visited by myself and Philipp. But if you have reason to believe that your account has been accessed without your permission, the best advice is probably to change all your passwords as soon as possible.
* Services that were accessible using this technique included: Google Alerts, Google Analytics, Google Base, Google Bookmarks, Google Code, Google Co-op, Google Docs and Spreadsheets, Google Finance, Froogle Shopping List, Google Image Labeler, Google in Your Language, Google Groups, Local Business Center, Google Maps (Saved Locations), Google Notebook, Personalized Homepage, Personalized Search (Search History), Google Reader, 3D Warehouse (SketchUp), Google Video and Google Webmaster Tools.
Labels: blogoscoped, google
