Facebook exploit – Confirm website visitor identities

http://www.tomanthony.co.uk/blog/facebook-bug-confirm-user-identities/

by TomAnthony • 7 years ago

219 51 7 years ago

tomanthony.co.uk

supernovae• 7 years ago

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• 7 years ago

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• 7 years ago

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.

jcims• 7 years ago

The thing to also keep in mind is that the bug bounty teams are typically centralized and not embedded within the product teams of the services being reported on. They certainly get prioritized attention, but there are still layers of communication to report the issue, follow up with devs or reporter if there are questions or difficulties reproducing the issue, prioritize the issue, fix the bug and deploy to prod.

Not to say that’s the way it is at Facebook, just what I’ve seen in the past.

userxyz135• 7 years ago

It's common in the bug bounty community to write about how you found the bug and how the reporting process went.

dpwm• 7 years ago

are we looking for something else here?

No. But some people, myself included, are interested in this sort of thing.

It's also interesting to see the timescales of the fix. Posts like this demonstrate that the system worked, albeit perhaps a bit slower than we'd like to imagine.

Whilst the reports of bug hunting apparently within the scope of the bug bounty resulting in a legal team responding with a false dichotomy between an NDA or prosecution are particularly juicy, it's also nice to hear about the cases where that isn't the outcome.

paxys3• 7 years ago

Who is complaining about anything? It's a nice article about a neat little exploit, and the process to find it.

patorjk3• 7 years ago

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

eveningcoffee• 7 years ago

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

tptacek6• 7 years ago

It very much depends on the bug.

chipperyman5732• 7 years ago

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

asdfasgasdgasdg• 7 years ago

https://www.google.com/about/appsecurity/reward-program/inde...

Looks like up to $30k per bug.

ProAm• 7 years ago

$1000 bounty for this seems really low.

tptacek6• 7 years ago

Why? There's no market for this bug. Nobody else will buy it. If you found an equivalent bug in, say, Grubhub, nobody would think it was worth much more than a token bounty. Is it just because Facebook is a big company and can afford to pay more for every bug, or is there a particular reason you think this bug is super valuable?

crshstsh• 7 years ago

Pat! I've used your API Spy countless of times as a teenager. I used to always rename the wav explosion file and would ALWAYS drag the splash screen image to reveal your face! That is how often I used that application. Thank you so much for your contributions and I looked over your sites and am happy to see where you are. Thank you once again.

patorjk3• 7 years ago

No prob, glad it was useful :)! Heh, I used to wonder how many people who find that easter egg. I figured it'd be a cool little surprise for anyone who tried to move the splash screen.

TomAnthony3• 7 years ago

OP here. I had exact same experience (and was aware of your story!). I also found a similar Google bug which didn't receive a bounty [1].

[1] http://www.tomanthony.co.uk/blog/confirm-google-users-email/

patorjk3• 7 years ago

Kind of a bummer Google again didn't give a bounty for this type of issue, but also kind of interesting that we had the same experience. Also cool to hear you'd heard of my story before :).

saagarjha• 7 years ago

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?

notafrog2• 7 years ago

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

air7• 7 years ago

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

wolco2• 7 years ago

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

notafrog2• 7 years ago

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.

renholder• 7 years ago

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

dddddaviddddd• 7 years ago

https://web.archive.org/web/20190305014509/http://www.tomant...

aboutruby• 7 years ago

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

aiiane• 7 years ago

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.

cheeaun• 7 years ago

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

Sebb767• 7 years ago

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

Facebook exploit – Confirm website visitor identities

Related Stories