Hacking Google for Fun and Profit(blog.andrewcantino.com)
blog.andrewcantino.com
Hacking Google for Fun and Profit
http://blog.andrewcantino.com/blog/2011/12/14/hacking-google-for-fun-and-profit/
8 comments
I think these are fantastic finds and I'm even more shocked at Google's response to be honest. Companies like this are usually really defensive and threaten to sue you and cut off all your services.
It takes a bigger man (company), to admit they are wrong and reward people accordingly for helping them.
Although I would never be able to understand security on this level, it has always interested me since the days when hacking guides were galore across the Lycos and Yahoo directories
It takes a bigger man (company), to admit they are wrong and reward people accordingly for helping them.
Although I would never be able to understand security on this level, it has always interested me since the days when hacking guides were galore across the Lycos and Yahoo directories
Awesome post, love to see that even the great borg is human sometimes like the rest of us :)
Just curious for someone who knows more than me, couldn't all of these have been prevented by requiring all POSTs to the server have an attached CSRF nonce? Is there a downside to having a blanket policy like that?
Just curious for someone who knows more than me, couldn't all of these have been prevented by requiring all POSTs to the server have an attached CSRF nonce? Is there a downside to having a blanket policy like that?
Tokens would not have helped for the first two. They were logic errors; the attacker used Google features in ways they were not expected to.
The first was a GET request, not POST. Images have fairly lax cross domain restrictions. So while the attacking website can't see the image loaded from Google they can detect when the image doesn't load. Google was returning a non-200 response code for images the user can't see.
The second wasn't a traditional XSRF. Instead it was making the victim (unknowningly) edit a shared document created by the attacker. The attacker uses the feature of Google docs that shows all current editors to see the victim's Google account name.
The first was a GET request, not POST. Images have fairly lax cross domain restrictions. So while the attacking website can't see the image loaded from Google they can detect when the image doesn't load. Google was returning a non-200 response code for images the user can't see.
The second wasn't a traditional XSRF. Instead it was making the victim (unknowningly) edit a shared document created by the attacker. The attacker uses the feature of Google docs that shows all current editors to see the victim's Google account name.
I am in awe of your skills. This is the first time I have heard of this program and I must say that I am a little surprised at how little money they offer to developers in return for them exposing potentially catastrophic bugs. Some engineers at Google must be paid rough $500/hour and more so you would have thought that finding bugs of this magnitude for say $10,000 a pop would still be cheap.
> Some engineers at Google must be paid rough $500/hour and more
You reckon? I doubt that engineers are making ~$1m/yr...
But I agree, that the time spent by someone discovering a bug is worth well over $500. Let say you spend 3-4 evenings playing with it and you find something. that roughly translates into 2 full days of work. Assuming $500-700/day figure (which might actually represent a significant amount of engineers at Google) they should be paying at least $1-1.5k per bug. But even that is on a cheap side I think...
You reckon? I doubt that engineers are making ~$1m/yr...
But I agree, that the time spent by someone discovering a bug is worth well over $500. Let say you spend 3-4 evenings playing with it and you find something. that roughly translates into 2 full days of work. Assuming $500-700/day figure (which might actually represent a significant amount of engineers at Google) they should be paying at least $1-1.5k per bug. But even that is on a cheap side I think...
You are right. $500/hour might be a bit extreme but I think we both agree Google is extremely cheap!
That is very neat. Regarding the choice of charities, did Google let you choose any registered charity, or was it from a list of pre-selected charities?
It's pretty common for people to donate the reward. We're happy to do so for registered charities, and typically increase the amount donated. If a reward goes unclaimed we just make a donation to the International Red Cross.
Any registered not-for-profit.
Very nice write-up! Especially since RSnake stopped writing ha.ckers.org, great and educational reports have been rather scattered (unless anyone knows some good blogs on that subject? hm, makes me wonder if the sla.ckers forum is still up ...).
You conclude that these bugs are "subtle", but I don't quite agree. In some sense, ClickJacking is always "subtle"(vuln 2 and 3), and you can argue the same for any kind of side channel information leakage (vuln 1 and 2).
Except that clickjacking is known for years now and should be considered serious like XSS.
And the information leakage, well, it's IMO just not allowed to happen if you're a huge corporation implementing a worldwide single-sign-on identity service and many different types of web applications, while claiming to care about your user's privacy. It should be their number one priority and failing this means they're rolling out new features in a tempo that simply means they cannot hold true to claims about privacy.
Somebody else mentioned the tone of this article. While I'm not a big fan of the "jerk" attitude either when it comes to security testing (mostly because usually the bigger the mouth, the less interesting their feats), a security vulnerability is still a coding mistake that always ends up inconveniencing or endangering the privacy of the userbase. And I think that should be said. Which the author did. But he also downplayed the bugs by calling them "subtle" and then immediately praising Google for how lucky we are that they fixed them so quickly ... maybe I just do prefer the jerks, after all.
You conclude that these bugs are "subtle", but I don't quite agree. In some sense, ClickJacking is always "subtle"(vuln 2 and 3), and you can argue the same for any kind of side channel information leakage (vuln 1 and 2).
Except that clickjacking is known for years now and should be considered serious like XSS.
And the information leakage, well, it's IMO just not allowed to happen if you're a huge corporation implementing a worldwide single-sign-on identity service and many different types of web applications, while claiming to care about your user's privacy. It should be their number one priority and failing this means they're rolling out new features in a tempo that simply means they cannot hold true to claims about privacy.
Somebody else mentioned the tone of this article. While I'm not a big fan of the "jerk" attitude either when it comes to security testing (mostly because usually the bigger the mouth, the less interesting their feats), a security vulnerability is still a coding mistake that always ends up inconveniencing or endangering the privacy of the userbase. And I think that should be said. Which the author did. But he also downplayed the bugs by calling them "subtle" and then immediately praising Google for how lucky we are that they fixed them so quickly ... maybe I just do prefer the jerks, after all.
I love these type of posts. Thanks for sharing. How do you stumble upon these exploits? Do you purposely go searching for them, or do you just accident upon them?
In this case, I wanted to take Google up on their Vulnerability Reward Program, so I purposely went looking for security holes. I used Firebug and the Chrome inspector to search for issues.
Those are the kind of personal hacker blog posts I really like: most of the time spent was actually hacker-stuff and he presents the results - not 90% spent on an article of pointless musings for nothing but self-promotion.
Great content aside, I found the tone especially refreshing. Too often, it's "look how smart I am, and how stupid you all are" -- the brilliant jerk archetype.
Thank-you.