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