Hacker News new | past | comments | ask | show | jobs | submit login

Freelance pentesting in a nutshell:

   1. Research and find vulnerabilities
   2. Apply for bounty
   3. Parry legal threats
   4. Exit empty-handed



Alternately:

  1. Research and find vulnerabilities
  2. Notify company in good faith
  3. Parry legal threats
  4. Embargo for a reasonable amount of time
  5. Parry legal threats
  6. Publish report
  7. Parry legal threats
  8. Get academic prestige
  9. Parry legal threats
  10. Blog on emerging exploits
  11. Parry legal threats
Another option:

  1. Research and find vulnerabilities
  2. Sell on black market
  3. Get paid, possibly several times
  4. Die in suspicious car crash


Which is why my favorite is:

  1. Research and find vulnerabilities
  2. Publish publicly immediately


My current favorite:

  1. Research and find vulnerabilities
  2. Research company
  3. Notify company in good faith depending on result.
If they have recently misbehaved towards people disclosing vulnerabilities, publish publicly immediately.

If they respond with any sort of legal threats, stop communicating with them and publish publicly immediately.

If I expect the company to be reasonable (e.g. has a bug bounty, is known to respond reasonably, or even just is a tech company that can be expected to have a clue) I contact them openly, otherwise, I consider either contacting them anonymously first, or (especially if I don't like them and don't want to deal with them) publish.


Respectfully, I'm going to default back to what I said.

The "notify in good faith" really just fosters a culture of "scratch my back, i'll scratch yours". Frankly, as a white-hat researcher you can be as much of a bad actor as any company and this is a sort of moral hazard that fosters a culture of unfairness and insecurity. If you really care about the overall security of the industry or consumers, you will publish immediately and leave the moral hazard of "perks/special treatment" off the table.

The companies that are reasonable in the way that you describe would not be materially harmed by such a disclosure and do not (okay, rarely) have the most egregious kinds of bugs. It raises the bar for everyone to do this.

Basically, it's not about you; don't make it about you; just publish. Every day that you do not publish, some client could be catastrophically affected by the bug and the company could be seriously dragging-ass on the fix. You have no visibility into this.

(Side note: I'm a developer and I build all of my infrastructure. Getting caught with my pants down by a vulnerability disclosure would totally fucking suck and be 100% my fault. It's my neck on the line. So yes, it will suck, and I might hate you a little, but then I'll realize it's my screw-up and that I need better processes to proactively solve these.)


The situations could be avoided if the "security researchers" would ask permission first, or simply deal with companies who have an established (and validated) bounty program.


Made the original comment because my friends who do this professionally for a fortune 500 company share the same tales of woe--that would probably end just as badly if they weren't operating under the safety of a corporate megabucks legal department.


The situations could be avoided if the companies hired developers who have heard the word 'security' before, or got training for their engineers to learn secure coding practices and their sysadmins to learn secure server setup. If they're not going to make the effort to do those simple things, why should anyone else consider tip-toeing around the scumbags slapping together anything they can get to marginally work and then endangering the public with it?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: