To the bounty hunters

This was originally part of Bug bounty 5 years in but didn’t make the cut. I recently re-found it and want to share. This is all my opinion from the side of running bounty programs.

First of all, thanks. You have taught me a lot. After reading through many, many reports in my life my advice is:

• Untangle speculation vs what you know to be true through testing. Speculation is cheap and sometimes useful. Having a list of specific things you tested and your conclusions based on that is 10x more valuable.
• Don’t trade the quality of your report for speed.
• Favor understanding certain areas very deeply. All the best bugs were nowhere close to being found by anyone else
• Don’t incessantly ping reports, it never helps.
• Be explicit about what you did, what you know, and what you are theorizing about. All bugs boil down to a flawed assumption and this clarity will help us both find that assumption more quickly.
• Big communication tip: What would the company you are reporting do to fix this vulnerability? When would you believe this to be accepted risk? What are the tradeoffs?
• Its rare for teams to reconsider payouts, if this happens it will be because you brought some new information to the situation. Don’t argue just to try and get more.
• The black market is very unlikely to be a place you could sell a bug in a specific website or service. It is not “worth millions”. Please stop repeating this.
• Understand that finding a bug is only part of the process. Finding similar flaws, fixing them all in a non-hacky way, testing all take time and are beholden to other peoples timelines. Security teams: This is why you need to be able to fix anything yourself.
• Don’t ever submit anything with the words “social engineering” ever again.

Where to spend time

Getting a sense of where in the product companies want your attention is useful. Don’t be afraid to just ask but in absence its generally best to look in the product itself.

There’s also a huge difference between bounties for bugs in products (where vulns put the users entire env and data at risk) vs. bugs in services where vulns only put the data you give them at risk.

— Dino Dai Zovi, leader of thoughts

A service bug — A wordpress instance on a domain unconnected to the product. Owning this gets you a handful of usernames and passwords and the capability to deface a domain.

Its an issue, it should be fixed and rewarded but the lesson here was “have a better inventory of wordpress domains” which is not very illuminating.

A product bug — Facebook had a forgot password flow where to gain entry to your account you need to prove you own it. This was done via a “secret question”. There was a list of 10 or so secret questions you could choose from.

One of the questions was “What is your US drivers license number”. One day someone wrote in to bug bounty alerting us that the algorithm to determine your drivers license number was public in a few states. The inputs were first name, last name, date of birth, gender, etc — in other words the exact information you can view for any of your Facebook friends by visiting their profile.

This bug is excellent because it affected every user, had a clear problem and solution and surfaced a critically flawed assumption. This is exactly the type of bug any bounty program would be grateful for.