Re:Facebook exploit – Confirm website visitor identities
by patorjk on Monday March 04, 2019 @06:51PM
(#19306867)
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.
Re:Facebook exploit – Confirm website visitor identities
by crshstsh on Monday March 04, 2019 @10:03PM
(#19307768)
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.
Re:Facebook exploit – Confirm website visitor identities
by patorjk on Tuesday March 05, 2019 @12:57AM
(#19308413)
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.
Re:Facebook exploit – Confirm website visitor identities
by patorjk on Tuesday March 05, 2019 @01:03PM
(#19312562)
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 :).
Re:Facebook exploit – Confirm website visitor identities
by tptacek on Monday March 04, 2019 @07:46PM
(#19307176)
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?
Re:Facebook exploit – Confirm website visitor identities
by scintill76 on Monday March 04, 2019 @08:08PM
(#19307264)
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.
Re:Facebook exploit – Confirm website visitor identities
by tptacek on Monday March 04, 2019 @08:18PM
(#19307316)
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.
Re:Facebook exploit – Confirm website visitor identities
by statictype on Tuesday March 05, 2019 @12:57AM
(#19308412)
> 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.
Re:Facebook exploit – Confirm website visitor identities
by GoToRO on Tuesday March 05, 2019 @03:58AM
(#19309191)
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?
Re:Facebook exploit – Confirm website visitor identities
by zulln on Tuesday March 05, 2019 @05:06AM
(#19309485)
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?
Re:Facebook exploit – Confirm website visitor identities
by GoToRO on Tuesday March 05, 2019 @08:33AM
(#19310364)
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.
Re:Facebook exploit – Confirm website visitor identities
by chipperyman573 on Monday March 04, 2019 @07:25PM
(#19307067)
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"
Re:Facebook exploit – Confirm website visitor identities
by tptacek on Monday March 04, 2019 @07:50PM
(#19307186)
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).
Re:Facebook exploit – Confirm website visitor identities
by TomAnthony on Tuesday March 05, 2019 @03:36AM
(#19309091)
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.
Re:Facebook exploit – Confirm website visitor identities
by chipperyman573 on Friday March 15, 2019 @12:22AM
(#19396515)
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.
Re:Facebook exploit – Confirm website visitor identities
by tptacek on Tuesday March 05, 2019 @04:13PM
(#19314305)
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.
Re:Facebook exploit – Confirm website visitor identities
by TomAnthony on Tuesday March 05, 2019 @05:00PM
(#19314661)
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.
Re:Facebook exploit – Confirm website visitor identities
by paxys on Tuesday March 05, 2019 @02:50AM
(#19308905)
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.
Re:Facebook exploit – Confirm website visitor identities
by comboy on Tuesday March 05, 2019 @07:06AM
(#19309975)
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?
Re:Facebook exploit – Confirm website visitor identities
by paxys on Tuesday March 05, 2019 @04:34PM
(#19314457)
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.
Re:Facebook exploit – Confirm website visitor identities
by notamy on Tuesday March 05, 2019 @07:37AM
(#19310112)
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.
Re:Facebook exploit – Confirm website visitor identities
by air7 on Monday March 04, 2019 @07:19PM
(#19307024)
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).
Re:Facebook exploit – Confirm website visitor identities
by notafrog on Tuesday March 05, 2019 @05:06AM
(#19309488)
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.
Re:Facebook exploit – Confirm website visitor identities
by aiiane on Monday March 04, 2019 @10:26PM
(#19307859)
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.
Re:Facebook exploit – Confirm website visitor identities
by saagarjha on Monday March 04, 2019 @06:52PM
(#19306872)
> 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?
Re:Facebook exploit – Confirm website visitor identities
by notafrog on Tuesday March 05, 2019 @05:10AM
(#19309505)
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...
Re:Facebook exploit – Confirm website visitor identities
by dpwm on Monday March 04, 2019 @06:56PM
(#19306897)
> 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.
Re:Facebook exploit – Confirm website visitor identities
by abhisuri97 on Monday March 04, 2019 @06:47PM
(#19306847)
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).
Re:Facebook exploit – Confirm website visitor identities
by jcims on Monday March 04, 2019 @07:27PM
(#19307081)
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.
Re:Facebook exploit – Confirm website visitor identities
by DanFeldman on Monday March 04, 2019 @06:55PM
(#19306893)
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.
Re:Facebook exploit – Confirm website visitor identities
by abeyer on Monday March 04, 2019 @07:03PM
(#19306933)
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.
> 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...
[1] http://www.tomanthony.co.uk/blog/confirm-google-users-email/
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.
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.
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 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?
http://www.tomanthony.co.uk/blog/google-xml-sitemap-auth-byp...
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.
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.
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.
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.
They simply exist as a small incentive for folks who would have otherwise done nothing.
Looks like up to $30k per bug.
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...
Then Facebook started requiring a password to make changes to page administrators, but they never returned the page to him.
Perhaps browsers need to expand the potential effects of access-control-allow-origin.
It's interesting that there wasn't any rate limiting on this API, it seems like?
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?
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.
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).
Not to say that’s the way it is at Facebook, just what I’ve seen in the past.
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.