

Hacking Google for Fun and Profit - tectonic
http://blog.andrewcantino.com/blog/2011/12/14/hacking-google-for-fun-and-profit/

======
_djc_
Well done -- an accomplishment indeed.

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.

~~~
tectonic
Thanks :)

~~~
tintin
I also like the way you spent the money. There are a lot of articles on HN
about how to get rich. But you gave a nice example of loving your job and
caring about society.

------
chrislomax
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

------
wdewind
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?

~~~
underwater
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.

------
richardburton
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.

~~~
rytis
> 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...

~~~
richardburton
You are right. $500/hour might be a bit extreme but I think we both agree
Google is extremely cheap!

------
stephenhamilton
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?

~~~
justinschuh
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.

------
tripzilch
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.

------
vinhboy
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?

~~~
tectonic
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.

------
kahawe
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.

