Hacker News new | past | comments | ask | show | jobs | submit login
Facebook exploit – Confirm website visitor identities (tomanthony.co.uk)
219 points by TomAnthony 15 days ago | hide | past | web | favorite | 51 comments



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


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.


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.


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/


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


$1000 bounty for this seems really low.


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?


TFA: "In addition, the most sinister exploiters (e.g. a repressive regime) of such a bug would likely have a list of people they cared about identifying (which they could also narrow down based on your location and other factors)."

Wouldn't such orgs (or their vendors) pay at least $1k to find the people they want? I don't know what the right formula is to calculate bounty vs. expected black market value, but you only said nobody would buy it at all.


My semi-educated guess at the answer to your question: no, China or Bahrain or whoever is not going to pay this guy $1000 for the differentiated error to a cross-domain request to Facebook; also, it's pretty hard to believe that there aren't 100 other ways to accomplish this attack, especially if you're a "global passive adversary" and can use traffic-analytic attacks to conduct it.

It's worth finding and fixing these problems, and that's what happened here. It is not a significant economic event, though, and it would be a surprising departure from normal payouts on bounties to see this get much more money than it did. The only reason it was surprising Google didn't pay out for the same bug is that it's Google --- most sites would assign this bug $0.


> no, China or Bahrain or whoever is not going to pay this guy $1000 for the differentiated error to a cross-domain request to Facebook

Feels like a strawman.

You know what they say about selling - solutions, not features.

This isn't a 'cross-domain request' any more than Stackoverflow is a UI on top of 'select * from Questions order by Date desc'

It's a visitor identification system.

That said - I have no idea if this solution is something people will pay for. Especially given it needs an exploit that can be fixed once by one company and instantly sealed.


If you participate in a bug bounty program you already decided you will not sell it on The Market. As such you should be payed for your effort and time at least. Otherwise you sell it to whoever pays more (on The Market).

If you read how much effort is put into just reporting the bug, that will come close to a half month at least. Is $1000 half a security research's salary?


That is a strange way of thinking about it. Should not Facebook instead incentivize the kind of bug they are interested in, rather than caring how long time it took to find?


They should evaluate fairly how much damage that bug would produce if used by bad actors and pay a percent of that. This is how I see it. Otherwise they are just relying on someone's passion and ethic to stay safe.


That's essentially what they are doing. You just dispute the percentage they assign.


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


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


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


Just curious as an academic matter here. What’s the legal risk from an exploit like this?

Is the idea that manipulating URL’s like that for the victim site amounts to unauthorized use of their computer, hence CFAA stuff?

Just curious how an expert would draw the line between black hat SEO and TOS violations and actual illegal acts.


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.


Just to clarify, when I said market value I was referring to the highest price you would get if you sold it on the open market (of course in this case you wouldn't just list it on ebay). Which is different from Google's bug bounty program as they are the only buyers in that system and could offer you as little as they wanted (or nothing at all), and you would have no recourse.

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.


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.


If you are in this business you are already connected with grey/black elements. Probably less risky than initially seems.


Plus I think it's safe to assume that they can handle themselves, anonymity wise. Tor and bitcoin is not rocket science


Bug bounties don't exist to prevent people from selling exploits on the black market. Those who were going to do so will do it anyways, and companies don't want a scenario where they have to bid against other buyers for such reports.

They simply exist as a small incentive for folks who would have otherwise done nothing.


I don't understand your reasoning. If you are a black hat and you can get more money for the bug from the company than from selling it on the black market, why would you sell it on the black market?


That's not what I said. A black hat can still try and sell it to the company, but (1) it won't be through the bug bounty process and (2) they are likely not going to pay "market price", whatever that is.


Because maybe I can report it once to the company and make X amount of money, but if the black market price is X / 2, I can potentially sell it many times and make significantly more than X.


What I mean by black market price is total amount of money that you can make on that bug selling it on the black market.



It very much depends on the bug.


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


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


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.


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.


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


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


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?


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


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


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


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.


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.


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.


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


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


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


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


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


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





Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: