arice

[HackerOne CTO here]

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

https://motherboard.vice.com/en_us/article/inside-stalkerwar...

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

Great feedback, thanks.

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.

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

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.

[1] https://developers.facebook.com/docs/facebook-login/security...

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.

FYI: Facebook has open sourced this tool, you can find it on github. Here's the commit that added Bootstrap: https://github.com/daaku/rell/commit/64bd62d40df54ddc08a9270...

Unfortunately, much of the internet industry has an established history of doing just that. This heavy-handed approach to vulnerability disclosure has led to an atmosphere of distrust and is bad for everyone. Facebook's policy is intended to alleviate much of the tension involved with vulnerability disclosure.

If you're curious, the EFF has published a number of great articles on the topic:

https://www.eff.org/issues/coders/vulnerability-reporting-fa...

https://www.eff.org/deeplinks/2010/12/knowledge-power-facebo...

Facebook's Responsible Disclosure Policy applies to all Facebook properties. The exceptions you outlined specifically apply to our bounty program. Basically, we may not pay a cash reward for a security issue reported in Mailman (an open source tool), but we still appreciate the responsible disclosure and you absolutely shouldn't be worried about a lawsuit.

I manage Facebook's Whitehat program (https://www.facebook.com/whitehat). We have taken an incredibly open stance towards security researchers and welcome the contributions they make towards securing the internet. Our policy towards this research is documented quite succinctly:

"If you give us a reasonable time to respond to your report before making any information public and make a good faith effort to avoid privacy violations, destruction of data and interruption or degradation of our service during your research, we will not bring any lawsuit against you or ask law enforcement to investigate you."

His attempt to access data was outside our whitehat guidelines, had clear malicious intent, and included extensive and destructive efforts to remain undiscovered and anonymous. In addition, he made no effort to contact Facebook with his discoveries, and even denied involvement when initially questioned. His attempt to claim he intended responsible disclosure only after faced with criminal action is false and insulting to the community of responsible security researchers.

Not every computer is guaranteed to be free of malicious software capable of acting on behalf of the individual. This necessitates that security filters operate on private communications. This is true for all messaging products.

An example of why this filtering exists: http://blog.trendmicro.com/koobface-makes-a-comeback/

Yishan Wong makes some interesting points:

http://www.quora.com/Are-Foursquare-and-Gowalla-going-to-sur...

I'm a confused user: The field didn't tell me what I should put in, so I just typed Bob and it worked.

The same choice is still possible on Facebook, no? There is a default-unchecked "Keep me logged in" box and a Logout button.

FWIW, the previous default was "Friends and Networks", not "Friends and Family". That includes Networks like the United Kingdom with 20M users and no restrictions on who could join.

Haha! If that is a virus, then so is this:

http://news.ycombinator.com/item?id=1354731

:-)