Facebook was right to not pay Streateh

This article should not be construed as legal advice.

Facebook deserves some credit for not paying Khalil Streateh for reporting his Facebook vulnerability.

It could not have been an easy decision knowing the likely sour reaction from the public, but they avoided the easy short term option to simply pay him and make the problem go away.

In the past few days, Streateh has attracted a lot of support from the media, parts of the hacker community, and the public in general for his attempt to report a security issue to Facebook and claim a bounty.

As my business is built on operating bug bounty programs, I've taken a keen interest in the dialogue and I've heard a number of interesting discussions, mostly about how Khalil did a good thing for Facebook.

In part, I agree — Khalil deserved a bug bounty reward for his finding. But the story isn't black and white, and the reasons Facebook haven't awarded him any cash are valid.

Rewarding Khalil potentially erodes Facebook's security, could damage the fast-growing bug bounty industry, and most seriously of all, could erode the right of businesses everywhere to keep themselves safe from hackers.

There are big calls so to understand why, we need to delve a little deeper into the story.

Khali's bug wasn't as simple to exploit for gain as other vulnerabilities found and reported to Facebook's bug bounty program, but because Facebook's business is built on maintaining the trust of millions of non-technical consumers worldwide — and this bug threatened that trust — it was serious.

The fact that Khalil could use the bug to compromise the public presence of the company founder makes it evident that Facebook should have paid more attention to this issue when it came in.

It's frustrating to have your bug ignored – and Khalil Streateh's bug deserved a bug bounty --but he won't get one.

Despite the external pressure Facebook has received over the past few days, I think they deserve credit for that decision as well.

Paying Khalil

Streateh won't receive a bounty strictly because he broke the terms of Facebook's Whitehat program.

That said, it appears Streateh broke three rules of the programme: that he give Facebook “reasonable time to respond to the report; that he not interact with other accounts without owner consent, and that he use a test account to investigate the bugs which would allow the flaw to be reproduced.

The rules are important because they are much of what stands between a safe, specific, monitored testing of mission-critical systems and a chaotic free-for-all where businesses, systems and customers can get hurt.

Paying Khalil would send a message that it doesn't matter about the rules if you think the bug is important enough.

I know a lot of security researchers who I think could be trusted with this sort of discretion but then there's everyone else.

That attitude would quickly spread beyond Facebook. The operators of other bug bounty programs would also be expected to abandon their rules in the wake of this decision.

Even tech companies not yet running a bug bounty program could be affected.

If Facebook had decided to pay Khalil for reporting this issue it may erode the legal principle that hacking a computer system without permission is illegal, provided you have a good reason.

That's a pretty scary precedent to set.

How can other bug bounty hunters learn to from Khalil's pain?

• Don't assume unbderstanding: The bug bounty CERT may not understand your bug or why it's important. Write your bug report like you're sending it to someone who understands some development, but doesn't really get security. This is not usually the case, but thinking like this will help you write a better report that get's investigated, fixed, and rewarded.

• Write good reports: Khalil's initial bug report described what the issue allowed him to do (i.e. post on others' walls) and included a link to evidence that he'd been able to exploit the issue, but didn't include any detail about how he did it, what part of Facebook was vulnerable, what tools he used, or anything to support the fact that he had actually exploited the issue and not just faked the link.

• Read the rules: The Facebook Whitehat terms and conditions contain a total of 414 words, and appears to be deliberately written in a way that gives non-English speakers the best possible chance of understanding it. Not having read and understand the rules is not an excuse not to follow them. It's annoying, and it goes against the ‘easter egg hunt' vibe around bug bounties, but it's necessary.

• Without permission what you're doing is illegal: Consider this clause from the Facebook Whitehat terms: “If you… [follow these terms and conditions] we will not bring any lawsuit against you or ask law enforcement to investigate you. – Khalil violated one of these conditions and Facebook reserves the right to pursue people who do. It's best not to poke the bear.

• Be thorough: When you submit an issue, make sure you include the following (in order of importance):

1.  
   1. Clear instructions on how to reproduce the problem
   2. Where the problem is located (page, field, parameter, etc)
   3. Description of the business impact of the problem
   4. Description of the technical impact of the problem
   5. Screenshot (Lot's of bug bounty hunters seem to think that this is the most important thing… It's not. It's also the most easily and commonly faked.)

How can other bug bounty teams learn from Facebook's pain?

• Treat everybody like they've found something real: The Facebook engineer who received the report responded to seek more clarification, but didn't seem to be taking Khalil very seriously. Treating people without respect shortens their patience, increases their frustration, and encourages them to take actions you might regret later.

• Help the tester to report well: Khalil sent a clarification but again failed to describe the important part — how to reproduce the issue. Facebook's team could have helped him by explaining more clearly what they needed to know.  (Researchers: See Be thorough above).

• Don't lose patience: Give them the benefit of the doubt. The Facebook engineer appeared to be fed-up in his follow-up email stage and responded with “This is not a bug. Obviously this was a mistake on his part, both factually but also psychologically — he challenged Khalil to a geek battle of knowledge and of patience. Security researchers, bug bounty hunters, engineers and almost anybody who is proud that they know anything about software will usually be proud of what they know, or believe they know. If you're dismissive of their knowledge and you disrespect them they might feel that the only way for to recover is to fight back (and post on your CEO's wall).

• Make your rules clear and easy to find: Facebook does, but that's atypical. Test your rules with a sample audience of potential testers and see whether your target community understands what you want them to do, and what you prohibit them from doing. If a lawyer has to touch your rules, make sure you test them again afterwards — lawyers don't test.

• Combat 'noise fatigue': Bug bounties generate a lot of noise. Separating out the signal from the noise is easy at the beginning, but it gets harder as your program and testing community grows, and your team understandably gets tired. If you don't fight that fatigue, you risk missing a bug like Khalil's, valid and reported but hidden from you by noise.

This article first appeared on BugCrowd, reprinted with permission. BugCrowd runs bug bounty programs for companies across the banking, retail, software and telecommunications industries.

Copyright © SC Magazine, Australia