1. 8
  1.  

  2. 16

    At this point, it was reasonable to believe that Wes was operating on behalf of Synack. His account on our portal mentions Synack as his affiliation, he has interacted with us using a synack.com email address, and he has written blog posts that are used by Synack for marketing purposes.

    Sorry, but that’s a load of crap, and the author knows it. He didn’t like what Wes was doing and called his boss.

    1. 5

      This assumes two things: 1) what Wes was doing was otherwise defensible, 2) Facebook did not have legimate reasons to believe that Wes was operating on behalf of his employer. I think both of these are poor assumptions.

      The initial RCE discovery was fine, and Wes seemed to be behave appropriately up until that point. But using keys discovered during an already disclosed exploit to engage in further exploits is wrong. As someone on Hacker News explained it, it’s roughly equivalent to breaking into someone’s house, telling them so they can fix the way you got in, but also taking their access card for work while in the house and then using that to access their office. The second exploit is illegitimate, because it was only possible due to a now-fixed flaw. Worse yet, it’s pretty ethically indefensible to justify stealing from someone and then using the products of your theft to demand more money. Facebook was reasonable in assuming he was a malicious actor.

      This leads into the second point, that Facebook had a reasonable belief that Wes was working on behalf of Synack. Given that all of his communications had come from a Synack corporate email address, that his account on their bug bounty system listed him as a Synack employee, and that he also has publically verifiable connections with Synack through his posts on their blog system, I don’t think it’s unreasonable that they believed he was participating in the bug bounty as part of his job. Furthermore, if they believed he was a malicious actor (which they certainly appear to have believed), then contacting his employer was likely the best way to limit the possibility that he could use the information he had obtained to cause harm (along with, presumably, locking down their AWS setup so that he no longer had access).

      This is not to say that Facebook acted perfectly in this situation. Their emails to him were admittedly unclear, and they seem to have rules for their bug bounty program that are not listed on the official site. Both of these things should have been different. But Wes too is not blameless. Security researchers have to show a lot of caution when pentesting other entities, particular when that pentesting is not specifically invited (which in this case would have meant Facebook directly hiring Synack or Wes himself to pentest them).

      All turned out alright in the end. Facebook secured their systems. Wes retained the payout for the initial RCE, and didn’t face any sort of charges for his actions beyond that. But this is not a story of the big bad company trying to take out the heroic little guy trying to make them more secure. This is a story of a well-intentioned pentester engaging in some ethically questionable behavior with lack of direction from Facebook, and Facebook responding to that behavior.

      If you’re a business, the thing to take away is this:

      • Make sure the rules of your bug bounty program are as clear as possible. While this won’t stop malicious individuals from going further than you’d like, it lets security researchers know where the line is, and reduces the likelihood of excessive data/system access beyond what you’re comfortable with
      • Be as clear as possible in communication with bug bounty participants. If a bounty is not being accepted, the more information you provide, the less likely the person is to misunderstand what you’re saying, or to attempt to access systems beyond what you’d want

      If you’re an individual or business engaging in a bug bounty program:

      • Be very careful to follow the rules of the program. If you’re unsure of whether a particular action is within the bounds of the rules, contact the company and ask. This is not an “ask for forgiveness” type of situation. You are dealing with live systems and real people’s data, and you need to be respectful of the bounds put in place by the company operating the bounty program
      • Never dump data from one exploit to fuel the discovery of future exploits unless you have been clearly and explicitly asked to do so by the operators of the bounty program. There are major legal and ethical concerns otherwise.

      Hopefully everyone can learn these lessons, so companies can feel a little safer running bug bounty programs, and individuals and businesses can feel a little safer participating in them. Everyone wins.

      1. 3

        As someone on Hacker News explained it, it’s roughly equivalent to breaking into someone’s house, telling them so they can fix the way you got in, but also taking their access card for work while in the house and then using that to access their office. The second exploit is illegitimate, because it was only possible due to a now-fixed flaw. Worse yet, it’s pretty ethically indefensible to justify stealing from someone and then using the products of your theft to demand more money. Facebook was reasonable in assuming he was a malicious actor.

        That doesn’t ring true. He pointed out deficiencies the Facebook devops team should have taken care of, but didn’t. Therefore he simply informed of the severity of the issue, and did nothing like breaking into anyone’s office. It is correct in that he couldn’t have gotten to the soft underbelly without the first vuln, but the bad design would still have been there. Hey, it might still be!

        And he never demanded more money.