sushi_ninja

I am 4chan.

Wait, that's not right...

It depends on if you’re talking about hackers researching to create their own exploits, or if you’re referring to a hacker that’s looking for others’ exploits to use ;). Many bug bounty programs’ scope are largely focused on appsec, so I’ll focus my answer there for now. In the realm of web app security, using a proxy is one of your best bets if you’re interested in getting started hacking. I personally like Burp Suite (https://portswigger.net/burp/). You can also check out Google Gruyere’s codelab to get started on basic appsec (https://google-gruyere.appspot.com/). The interesting thing about appsec as it relates to bug bounty programs is that some of the most interesting vulnerabilities you end up finding are very specific to the company in question. I’d recommend checking out Peter Yaworski’s Web Hacking 101 book for real world examples: https://leanpub.com/web-hacking-101.

If you’re looking at more general exploit development, it really depends on what you’re trying to exploit - that’s a pretty big question :). Generally speaking, “fuzzing” is something you’ll want to become familiar with (https://en.wikipedia.org/wiki/Fuzz_testing) and is widely applicable in exploit dev in a variety of areas.

Ahhh, BugCrowd :). HackerOne and BugCrowd are both “together” in helping promote the bug bounty ecosystem, but obviously we are competitors in this space ;). Our mission is to make the Internet more secure, and if BugCrowd can also help with that, awesome.

There are great arguments on various sides of this issue. The breakdown on HackerOne platform data is currently: 18% pay at validation, 34% pay between validation and resolution, 48% pay at resolution.

• Rewarding quickly for a severe vulnerability can be a reflection of its priority and a signal to the researcher of its importance to you. An initial bounty can be supplemented later if it was even more severe than originally thought.
• Vulnerabilities with exceptionally long resolution times shouldn't delay a bounty. Consider awarding upon validation for these.
• Awarding at time of resolution can help ensure accurate bounties by giving you time to correct any validation mistakes.

We recommend a middle ground: award bounties within 30 days of validation.

That said, in my experience, I lean towards paying out the bug once you know it’s legit and have assessed the impact/value of the bug to your organization. This implies trust in the hacker that disclosed the vulnerability to you, in that you believe the hacker understands it’s important not to disclose vulnerability details until the issue is fixed. In this model, the affected organization is responsible for notifying the hacker with updates on the remediation timeline, most importantly giving the hacker a head’s up once the issue is fixed. At this point, hopefully the company and hacker can work together on public disclosure to demonstrate a successful bug bounty interaction between both parties. There’s a lot at play here, and it depends largely on the company’s internal structure and relationships between the security team, developers, PR team, legal, etc.