This is part one of our two-part series on polite hacking, focusing on what to do. Part two talks about what not to do (link coming soon).
This blog is not about techniques. It’s not about tools to use, how to find the vulnerability, or anything like that. There are plenty of those out there. It’s much more like an etiquette guide for Bug Bounty reporting, and how working within these social norms can lead to better outcomes for you in your career! Think of it like a cotillion class, or the fanciest dinner you’ve ever been to, but for hackers.
The advice you’ll find here is more “Soft skills” related, but ask anyone around, soft skills get you work. Indeed lists several soft skills that are important in working as a developer; these are things like communication, patience, teamwork, and so on. So if you want to build a solid relationship with potential future employers, then maybe this blog is a good place to start. Let’s talk (well, I’ll type and you read) about what to do when bug bounty hunting.
Do
- Get Permission
- Stay in scope
- Be transparent
- Take your time
Get Permission
This is probably the most important thing on this list. Let’s say you’re walking through a neighborhood with a neighborhood watch sign. This usually means that the community is taking seriously the threat of outsiders and people looking to steal from, harm, or hurt the residents of that neighborhood. Well, you’re a good person, right? So you decide to help them stay safe by seeing how many houses you can break into! This will go well!
So you break into a house and leave a note, “I DIDN’T STEAL ANYTHING. But your back window lock is loose and I was able to use a thief’s tool to get in and leave this note!” How soon before the community calls the cops? Do you think they will show up, talk to you, and say, “Ah he was just showing the neighborhood where you’re vulnerable!! No jail for you!”
Of course not. You’re getting arrested!!
If a company wants people testing their systems, looking for bugs and issues and problems, they will have information about that available. If they don’t… well that means they don’t want you in their assets! You must have some kind of permission in order to test a site or asset for vulnerabilities or bugs. There is no way around that, from a literal legal perspective. Now what are you allowed to do once you have permission?
Stay in Scope
Often, companies will have a list of appropriate targets or assets they’re open to receiving feedback or reports on. They may also have a list of approved techniques or tools. Whether it’s disclosed through their own program or as part of an outside group like HackerOne, it’s important to know exactly what you’re allowed to do when checking for vulnerabilities and bugs. You can’t try to claim a bounty and feign ignorance of the rules of the bounty program.
“But I found a vulnerability in an out of scope site! They need to know!”As noble as that sounds, they clearly don’t want to know, and you’re not Batman.
It is up to the company to decide what is in or out of scope, not you. They are not your assets. If you want to remain an ethical hacker, that’s a hard stop for you. If you feel truly compelled and think they should consider including something new in the scope, then you can contact them through other avenues if you like, but know that most companies receive MANY emails and messages about their scope for programs. Consider the company's perspective: for some reason they don’t want that tool or asset in scope. And that reason, good or bad, has been decided.
Now, is scope a contentious issue? Of course! But I’m saying if you want to be polite about it, then be careful which scope fights you’re taking on and which you are letting go. Ultimately, perhaps a company’s limited scope is a reason you don’t partake in their program anymore. And that’s a totally reasonable approach, one that’s way better than forcing them to let you go beyond the rules of engagement set up by the program. And, possibly, this means that that’s not the right bug bounty program for you.
Take your Time
What’s the longest part of any offensive hack?
If you said reconnaissance, you’re correct! Gathering information about your target, learning who, what, where, how, and huh? is a lengthy part of the process, and you should go through it with the respect that period of time deserves. If you rush through this part of the work, it’s far more difficult to recover from an issue down the line. Gathering information, keeping that information organized well, and being able to access that information later is hugely important when it comes to bug bounty hunting. You need to make sure to take your time and not rush through the process to get to the bounty. The money is, of course, tempting. Every time I see the amounts being paid for bounties, MY eyes turn into dollar signs like some giant human Scrooge McDuck.
But you’re not going to get it unless you do the process the correct way. In this case, the correct way is meticulous; a hastily done and hastily written bug bounty is likely to get ignored in favor of one that is clearly well put together and well documented. You only get to be well documented by keeping good notes and results, nicely organized by whatever system works best for you. And while I have you, ProjectDiscovery has so many great reconnaissance tools (yes that’s five links. We’re good at this) available to help you through the most important part of any offensive action. You can also check out our reconnaissance series in our blogs.
Good Reports
We have some specific issue templates available here at ProjectDiscovery, and each one has plenty of comments to guide people in making issues for us that they want reviewed, looked at, or otherwise checked out. It’s frustrating when an issue is posted, and the information we asked for, the template we made specifically to make getting answers easier, has been ignored in favor of copy and pasting only the error message into the issue. This makes working with that issue immediately harder and more work than if the information requested had been included in the first place, because the first thing we’ll do with an issue like that is ask for that information and wait to get pinged when the user responds. That’s wasted time. The same is true for your bug bounty reports. Whatever method of submission they use should be adhered to; whatever information they request to be included in the instructions for the program should also be read carefully. These are often large programs with many submissions. These submissions are hopefully written well and have all the information needed. But many come in incomplete, inaccurate, or otherwise not useful. You can build a positive reputation as a bug bounty hunter if you are dependable and always submitting useful and accurate reports. That reputation can lead to better opportunities with the companies you work with.
It pays to be polite
When it comes to bug bounty hunting, the being polite can literally make it easier to get paid. You’re far more likely to get and grow payouts by following the rules and being a memorable hunter for your results AND great soft skills. But, don’t just follow these rules. Read on for the second part of our series (coming in November) on what not to do when bug bounty hunting.
