Bug Bounties: Tips from the Triager

I’ve spent the best part of the last 10 years triaging Bug Bounty reports that are submitted to the various cloud service providers that I’ve been charged with defending. I’ve also submitted a number of Bug Bounty reports over the years.

With these dual perspectives in mind, I wanted to write up a few tips for anyone who’s about to hit send on a bug report. One thing I want to make very clear from the get go — I personally approach every bug bounty report I get as though it’s the real deal and it will need to be actioned. If I get a good report, I will fight tooth and nail to get the issue fixed quickly, and reward the reporter accordingly. Unfortunately, Bug Bounty reports are generally high-noise, low signal — that’s why an entire industry has spun up to manage the triage process. But that signal, when it comes through, can be so valuable. It’s a double edged sword for most security teams, who aren’t short of things to be getting on with.

So, if you genuinely go into a bug bounty submission with the mindset of wanting to provide high quality, well produced signal — then here are my tips.

1 — Read the scope

If a company has a bug bounty program, it means someone on the inside has spent time advocating for it. Depending on the company, it can be hard to get buy in for a program, even in 2021. The scope of the program is frequently the outcome of a lot of internal negotiation. Respect it. Read it, and read it again. If you aren’t sure if a particular property or vulnerability type is in scope — ask before spend time examining it.

2 — Automated tools

Most companies will spray their web properties with automated security tools regularly. If all you’re doing is that, it’s probably not worth it. Automated tools are of course famous for finding the low-hanging-fruit that should be addressed, but other than that, they don’t find things that have significant value. Instead they just create a bunch of noise in the logs. Many bug bounty scopes rule out reports generated by automated tools for this reason.

3 — Read the scope

Yes, I know I’ve already mentioned it — but reading the scope is the single most important thing you can do before starting the process of submitting a bug bounty report. If you find a bug in a third-party product or service that impacts a company, chances are it won’t be in scope. By all means, report it on the off chance that they are not aware, but don’t be surprised if your report cannot be rewarded because the fix cannot be enacted by the company you’re reporting too.

4— It’s a bug bounty, not a best practices bounty

If you read a textbook on security theory, you’ll get pumped full of recommendations and best practices. If you then take that into the real world expecting to apply it seamlessly, well, I have bad news for you — business pressures and requirements mean that you can’t just do everything you want all the time. The art of security, is managing risk and keeping the company in business. If you find an old TLS cipher version in use, or something that isn’t strictly a bug — but just something that could be improved as a best practice, chances are, the team behind the scenes already knows about it and has been fighting for it for some time. Submit your report (if it’s in scope) but, don’t expect a reward because it’s not strictly a bug. If anything, the report could help add weight to the teams arguments.

5 — Read the scope

You probably sense a bit of theme here. Again, make sure you pay particular attention to the vulnerability types that are considered in scope. A vulnerability that can only be triggered by a client, against the user using that client, is probably not going to be in scope. If an attacker is already on a users machine in a position to trigger a client-side vulnerability, well, nothing I can do will really help them, as much as I’d like too.

6 — Consider the context

The severity of a given vulnerability is of course very dependent on the context in which it is found. Publicly accessible S3 buckets for example, can of course be a very bad thing — if they are hosting data that should not be public. If they are being used to host a publicly accessible website on the other hand — well, that’s not really a problem. Context is everything and doesn’t take long to discover.

7— Read the scope

Please just read the scope.

8 — Understand the application, at least a little

I’d strongly recommend taking the time to understand the function of the application you are submitting a bug report for. If you don’t know the intended function, or normal behaviour, how can you be confident that what you’ve found is truly a bug? Also, how can you identify things like bugs in the business logic? Use the application as a user, before using it as security researcher.

So there you go — a bunch of tips that will hopefully help. If you’ve read this far, then you can definitely make the time to read the scope. :-)