There are certainly some important lessons for us to learn here but, just for clarity, this wasn't one of them. The data access in question here was central to the individual's daily job responsibilities and done through systems explicitly built for this purpose.
That's helpful feedback on missing context from our post. Thanks.
This series by VICE articulates the sometimes subtle distinctions between legitimate monitoring software built for enterprises and parents vs this particular software (which they deem "stalkerware").
There are a lot of dubious companies on HackerOne. Why did taking a stance on this one have a perceived more positive outcome than taking any stance at all?
Pretty much zero of the companies on HackerOne are part of any social responsibility index, shariah compliant index, or trendy b-corporation index. And even in the non-zero rebuttal, the vast majority can have entire dissertations written about weighing the ethical considerations for doing any business with them.
So why even make a stance at all?
The time it takes for the arbitrary nature of your ethical decisions to become apparent is simply longer than it will take for your runway to deplete.
That's me, and I'm quite embarrassed as I never paused to consider how it could be interpreted.
That was a real story. Shortly after we established Facebook's bug bounty program, we received several vulnerabilities from a brilliant computer science student at Tyumen University (in Siberia). His dorm did not accept international mail, he did not have an accepted government ID (didn't drive), and figuring out how to pay him was a multiple month ordeal that Facebook's accounting team was completely not prepared for. It's something that we take for granted but international dispersements to every individual with internet access is actually an extremely challenging and unsolved problem.
Great questions. We'll line up a more analytical post on the topic as I don't know all the answers here, and we all should. In the interim, here's a few rough from memory answers:
> Thats an average of $357/vuln
The 14,000 includes resolved bugs where no reward was offered (Bounties are optional with ~40% of programs not offering any. i.e., "responsible disclosure", a drop in replacement for security@company.com). If you reduce the set to reports where a reward was offered, the average is closer to $750.
> What % of the $5MM or the 14K did the top hacker or group take home?
The top earner last year took $280k.
> How long is the tail of zero $$ per hacker in the community of the 2K?
This is a diverse group. Several hundred are active "hackers" driven financially. The rest are developers, hobbyist, technical consumers, who just happened to get curious about something in particular or even stumbled across a security problem in passing (this is far more common than you'd reasonably expect).
The 180 day guidance you reference falls under a "Last Resort" clause when "... the Response Team [is] unable or unwilling to provide a disclosure timeline". (which, at first glance, might not have been the case here?)
These "Last Resort" scenarios have not yet been fully codified. As a safety precaution, the workflow is still initiated manually with support as these scenarios are extremely rare and littered with edge cases. We've been learning a lot from studying disclosures like this one and you can expect to see the "Last Resort" workflow codified in the product in the future.
Now that the report has been Resolved, you should see the normal disclosure options available. Please always feel free to send me a note if you have any questions or feedback on our disclosure workflows - especially if we don't support your preferred route.
The stance you take is harmful when said organizations are responsible for the stewardship of the data of others, and being "less secure" places the general public at risk. The true impact of a breach is rarely limited to a single organization.
It is even further harmful when the laws are aggressively applied to prevent research into personal property, especially when your personal safety may depend upon it. For example, your car: https://twitter.com/0xcharlie/status/600729130355666944
I don't make a habit of storing assets in banks that fail to insure me against a total loss of those assets. That insurance just happens to require extensive third-party verification of security practices that may be publicly audited upon request.
The analogy doesn't hold when applied to the digital services we all depend upon as such assurances are impossible.
> The analogy doesn't hold when applied to the digital services we all depend upon as such assurances are impossible.
Rather than allowing anyone to try to crack a server as long as they claim to be a white hat, I'd much rather require corporations to go through a standard, "extensive third-party verification of security practices that may be publicly audited upon request" and default cracking attempts to "illegal."
I may be misunderstanding something in what you're saying, though -- if I am, could you clarify that for me?
This is great work by Egor, as usual. I work on Facebook's security and thought I'd add a bit more clarity here on the mitigation steps available to developers. Awareness here is important.
The first issue manifests itself if 1) an account has been previously registered on a client site, 2) that site offers the ability to "link" that existing account with a Facebook account, and 3) the action that performs the linking on the client site is vulnerable to CSRF. If you're a developer implementing conditions 1 & 2, make sure the linking action is protected by your anti-CSRF framework. Requiring explicit consent prior to linking accounts is a good idea for a number of reasons beyond this attack.
The second issue builds on what Egor refers to as "OAuth's Achilles' Heel": if the client site contains Open Redirect or XSS vulnerabilities, those vulnerabilities can often be leveraged to compromise the OAuth credential. To greatly reduce the likelihood of this attack, you should restrict which endpoints on your domain are capable of participating in the OAuth flow. See Facebook's Best Practices for Login Security guide[1], specifically the "Specify a whitelist of OAuth redirect URLs" section. Of course, you probably want to fix any Open Redirect & XSS vulnerabilities as well.
Hopefully not too oddly: Facebook was one of the first OAuth 2.0 implementations and the additional benefits of requiring stricter pre-registration was not initially apparent. An unfortunate oversight. For kicks: compare section 5.2.3.5 v00 with v01
Changing the implementation at this point is a daunting task (for both Facebook and our developers) but we do hope to offer it as part of a future migration.
I'm very sorry you had this experience. We would never intentionally ignore a legitimate bug report. If you could send me a message (link in profile) with the e-mail address you used, I'd be happy to get to the bottom of this.
There are certainly some important lessons for us to learn here but, just for clarity, this wasn't one of them. The data access in question here was central to the individual's daily job responsibilities and done through systems explicitly built for this purpose.