
Facebook exploit – Confirm website visitor identities - TomAnthony
http://www.tomanthony.co.uk/blog/facebook-bug-confirm-user-identities/
======
patorjk
I found an exploit like this in Google+ back in 2013 that worked in basically
the same fashion (script tag and onload/onerror handlers) to identify users,
and to tell if they were apart of certain groups. Google fixed the issue, but
later wrote back:

> The panel has determined your report did not meet the threshold for a reward
> or credit in our Hall of Fame. Thank you for reporting this issue and good
> luck with your continued bug hunting.

That always kind of rubbed me the wrong way. I found a similar bug in Facebook
[1], though it used image size instead of the script tag. Like the OP, I was
given $1000. It definitely made me feel a lot more favorable towards
Facebook's security team.

[1] [http://patorjk.com/blog/2013/03/01/facebook-user-
identificat...](http://patorjk.com/blog/2013/03/01/facebook-user-
identification-bug/)

~~~
eveningcoffee
How much did Google offer for a security bug (if they would have accepted it)?

~~~
chipperyman573
A bug by the same author (referenced in the article) that allowed anyone to
undetectably upload a sitemap to any other person's website (and appear at the
top of search results by claiming to be associated with the website) only got
$5000, when it could have easily been sold for tens of thousands to blackhat
SEO companies. So the answer is probably "way less than street value but still
nonzero"

[http://www.tomanthony.co.uk/blog/google-xml-sitemap-auth-
byp...](http://www.tomanthony.co.uk/blog/google-xml-sitemap-auth-bypass-black-
hat-seo-bug-bounty/)

~~~
tptacek
That's a really good bug! But $5k sounds pretty reasonable, since the only
alternative market for it comes with pretty obscene legal risk (unlike an RCE,
which will have a whole variety of white- and grey- market buyers, an SEO bug
seller knows exactly what their buyer is doing with their work).

~~~
TomAnthony
OP here. Really interesting to get your take on that. From my (far less
security educated) POV the Google XML bug felt less risky from a monetisation
angle.

I guess the difference is between exploiting it yourself vs selling it. There
was a clear path to monetisation that didn't require selling the exploit on
the black market, and which could well fly under the radar (from my reasonably
well educated SEO POV).

However, I don't think bug bounties necessarily need to equal the 'market
value' of the bug, whatever that means.

~~~
tptacek
The logic I'd use is that selling a bug with full knowledge of the specific
criminal or tortious activity it will be put to use in is more dangerous than
selling a bug that has a relatively diverse market of buyers and for which
you'd have strong plausible deniability (not to mention a network of gray-
market middlemen insulating you from any actual knowledge of offenses). My
mental model of this is Stephen Watt --- but I only know the surface level of
what was reported in that case.

Generally just my logic would be: selling bugs for which there's an
established market is safer than selling one-off bugs to idiosyncratic buyers.

~~~
TomAnthony
That makes absolute sense to me, and I agree.

However, it doesn't cover the aspect that some bugs are directly monetizable
without needing to be sold (as was the case with my Google XML Sitemap
exploit).

Of course, there is a risk to directly monetizing such a bug too, but the risk
calculation is then different.

------
air7
I once (2009) found a similar bug that allowed leaking the ID and personal
info of a FB user when their browser loaded a seemingly innocent <img> tag (so
it could be embedded in a forum post, for example).

Sadly, it was before FB had a bug bounty program, so I didn't receive anything
after I contacted them and they fixed the issue. I wrote about it here:
[http://blog.quaji.com/2009/07/facebook-personal-info-
leak.ht...](http://blog.quaji.com/2009/07/facebook-personal-info-leak.html)

~~~
wolco
In 2009 they had private photos exploits, login exploits and all other kinds
open access issues. Fun times.

~~~
notafrog
A friend of mine used to have a Facebook page with about 180k fans back in
2008 or 2009. He was so greedy, he found some "javascript code to increase
fans" and ended up giving admin rights to the page to some "hackers".

Then Facebook started requiring a password to make changes to page
administrators, but they never returned the page to him.

------
aiiane
A question worth pondering is if this is something that should continue to be
fixed at the site level, or whether it's representative of an overarching
problem with the data that browsers make available around cross-origin
requests. access-control-allow-origin was supposed to be the means of
addressing cross-origin concerns, but in this case even its usage doesn't
prevent the issue.

Perhaps browsers need to expand the potential effects of access-control-allow-
origin.

------
saagarjha
> Because the endpoint is HTTP2 it also means you can have many of these
> requests in flight at once, which makes checking against large lists of IDs
> very quick.

It's interesting that there wasn't any rate limiting on this API, it seems
like?

~~~
notafrog
Not surprised. Back in 2016 there was a bug in Facebook beta where you could
bruteforce the verification code when performing a "forgot password" request.
There was no rate limiting...

------
supernovae
Is there something in here we're missing?

Someone finds exploit, gets the bounty, facebook fixes and we have a timeline.

Sounds like the system worked... are we looking for something else here?

~~~
abhisuri97
I don't think there's much to see here...it is a cool bug though that doesn't
require a super high level understanding of security to figure out.

But a 6-9 month time to fix seems really long (also I would have thought a
$1000 bug bounty is low for this type of exploit...but then again I'm not in
this space too much to know the average rewards).

~~~
DanFeldman
Being charitable here, it may be that this exploit showed a breakage in their
internal API security process, or an edge case previously unhandled. Perhaps
FB had to run an internal audit to find any other endpoints effected by this
bug. Buggy endpoints then need to get fixed, tickets get sent out, but with a
low priority because this is a low priority bug, and voilà, 6-9 months.

~~~
abeyer
One could also question whether they used the lure of a bounty to keep someone
quiet while they let customers (aka advertisers) continue to benefit for an
extra 9 months at the expense of the users.

I guess you'd have to consider Facebook's track record in terms of how
charitable vs. cynical you want to be in interpreting their actions.

~~~
baroffoos
Couldn't facebook just provide some secret service for identifying users
behind the scenes that regular devs can not access?

------
aboutruby
One nice thing about GraphQL is that there is only a few endpoints to secure
instead of thousands.

------
cheeaun
Just wondering, how or what was the fix for this exploit?

~~~
Sebb767
In this case, it's probably just prefixing both requests with the protection
against embedding and sending the same headers.

------
renholder
Did someone get a grab of it, by any chance? Getting 502 bad gateway from
Cloudflare.

~~~
dddddaviddddd
[https://web.archive.org/web/20190305014509/http://www.tomant...](https://web.archive.org/web/20190305014509/http://www.tomanthony.co.uk/blog/facebook-
bug-confirm-user-identities/)

