As a Bug Bounty hunter it can be frustrating to submit a report and have to wait for a long time to get a response, have your report closed as duplicate/out of scope, or receive a reply from the triage team requesting a better explanation of the impact and to improve your PoC (proof of concept). Early in my career I was a Bug Bounty Triager and I wanted to write this to provide some insights on what happens behind the scenes when a Bug Bounty report is submitted.
Before a Bug Bounty program is created, many things need to be in place. The security team has to:
- Be very familiar with what public facing assets the company has
- Be very familiar with the development and infrastructure teams
- Know who to contact depending on what issues are reported
- Have the skills to understand the severity and verify the report is valid
- Have the customer service skills to interface with the hacker in a friendly manner
- Have support from senior leadership
Without these fundamentals, a Bug Bounty program is unlikely to be successful. To put these in another perspective, when I received a new report, these are the questions I would ask myself:
- Is the reported issue in scope for the program?
- Can I validate the issue is accurate with the provided PoC?
- What is the impact to the business if this issue were exploited by a Black Hat Hacker?
- Who do I contact internally to get the issue fixed?
- How does that team like new tasks to be added to their backlog?
- How do I explain and demonstrate the risk so they understand it?
- How will they prioritize the issue with their other tasks?
- Are there compensating controls that can be used to mitigate the risk?
- Could this issue exist in other areas?
Assuming the report is valid and in scope, I would normally create a ticket for another team to make a change and fix the issue. Depending on the workload of that team and priority of their other tasks, it could take them weeks or months to complete the fix. During this time I would often receive new messages from the Bug Hunter asking for an update, and I would do my best to be friendly and provide realistic expectations. Every Bug Hunter was unique, and some were understanding, while others would get frustrated and threaten to make the issue public if they weren't paid in a timely manner. This is part of the reason why many Bug Bounty programs are invite-only and curated so only respectable Bug Hunters participate in the program.
It wasn't uncommon for service owners to contact the security team and ask about unusual activity. Sometimes the scanners that Bug Hunters use can negatively impact services. If we were able to identify which Bug Hunter is causing the negative impact we would contact them and ask them to rate limit their scans, or simply ban their IP to protect the service. When reviewing logs it is not always easy to tell the difference between a Bug Hunter and a malicious hacker. This is why sometimes programs request that a unique user-agent is used, so it is easy to attribute scan activity with a specific Bug Hunter.
When the report involves a Remote Code Execution vulnerability, or the PII of customers/employees, it is typically treated as a P1/Critical issue. This is when the security team kicks into high gear and performs Incident Response. To me, conducting Incident Response was like being a "Digital Firefighter". Adrenaline kicks in and you have to try to think clearly and contain the issue as quickly as possible. Leadership must be informed, on-call people sometimes need to be paged, logs need to be reviewed, a timeline must be created, and other priorities take a back seat until the issue is contained. In this context, containment means that the risk is mitigated and can no longer be exploited.
 |
| Incident Response: Digital Firefighting |
In June of 2021 Lesley Carhart posted an excellent photo of her heart stress during an incident:
Once an issue is fixed, I would message the Bug Hunter to ask them to verify the issue is fixed. Once everyone agrees it is resolved we would reward the Bug Hunter. The reward amount was often a discussion point within the team and many factors were considered. Primarily: "What is the impact to the business if this issue were exploited by a Black Hat Hacker?".
The work I did as a Bug Bounty Triager early in my career taught me a lot about Application Security, Penetration Testing, Incident Response, and Vulnerability Management. It inspired me to dive deeper into these topics and eventually learn how to do some Bug Hunting of my own. In May of 2021 I received my first paid bounty for two findings I submitted through HackerOne.
I am happy to see that Bug Bounty programs are being created by so many companies out there. It is a great opportunity for companies to improve their security, and for ethical hackers to get paid for doing what they love.
If you are interested in becoming a Bug Hunter, or just like to learn how hackers do their thing, I highly recommend these learning resources:
HackerOne CTF https://ctf.hacker101.com/
PortSwigger Web Security Academy https://portswigger.net/web-security
HackTheBox https://www.hackthebox.com/
TryHackMe https://tryhackme.com/
PentesterLab https://www.pentesterlab.com/
Many of these learning sites have built-in guides or you can find high quality guidance on Youtube
No comments:
Post a Comment