100 hours of bug bounty on a public Hackerone program. Bounty vlog #1

Introduction

Welcome to the long-awaited bounty vlog number one, where I will share my challenge of conducting 100 hours of bug hunting on a public program from HackerOne. In this article, I will detail the program I chose, my approach, the vulnerabilities I reported, and the eventual earnings. You'll also find a pathway to my notes and methodology.

Background

For those who haven't seen Bounty Vlog #0, let me quickly introduce myself. I have a solid web security background, having worked as a pentester for three years. However, when it came to bug bounty hunting, I found myself jumping from one program to another without much success. Up to this point, I had only one monetary reward, which is discussed in a previous video on this channel.

During a podcast with David Shoots, he mentioned that understanding the flow of an application allows bugs to come naturally. Intrigued, I decided to test this theory by investing 100 hours in a bug bounty program. Importantly, I aimed to grasp different flaws in the application rather than simply searching for bugs.

Program Selection

The program I chose was Stripe, a payment provider I personally use for handling payments. Stripe mainly operates through an API, but also has a dashboard and encompasses several other assets within its scope.

My Approach

I started my first session on Stripe, which lasted three and a half hours, focusing on the flow that subscribers to my pay newsletter would experience while subscribing. During this exploratory phase, I understood the requests and parameters but didn't find any vulnerabilities. After a few days dedicated to creating a video, the idea struck me to test archived prices from my subscription—particularly since I had recently increased the price.

Initially, I tried using the old checkout link to no avail. However, I then began the flow with the new link and changed back to the previous one mid-way, allowing me to complete the purchase at the old price of $ 48 instead of $ 79. This discovery marked my first report on HackerOne in almost two years, and the excitement was palpable.

The bug was triaged as medium severity, which I found fair, given that the payout range for this type of vulnerability on Stripe’s API is between $ 1,000 and $ 5,000. I received a reward at the lower end of that range but was pleased, considering the time I had spent.

Subsequently, I spent time understanding more flaws in Stripe's system but wasn't able to find further bugs. I decided to explore other assets under the program's scope, which included Stripe’s GitHub repositories housing their SDKs. After a couple of days, I discovered a bug, and even though it was challenging to exploit, I reported it. This bug garnered a reward of $ 500 classified as low severity.

By this time, I had earned $ 1,600 after just 24 hours of hunting, which was a promising start. Yet, as I continued my search through the remaining time, I struggled to find new bugs. After spending 60 hours focused on Stripe’s domains, I began feeling unmotivated, ready to end the experiment early.

The Turning Point

However, after 82 hours, I found another bug within an open-source application on GitHub, leading to my highest payout yet. This bug was also classified as low, yet I received an additional $ 1,000 in bonuses for actively contributing to the security of that specific asset, totaling $ 1,500 for that report.

After completing the 100 hours of hunting, I saw my total earnings amount to $ 3,100. Subsequently, I have questioned whether to pursue follow-ups on these bugs, especially since the original submissions contained elements that weren't adequately addressed post-triage.

Reflection and Takeaways

After concluding my 100 hours, I reflected on my earnings. Although not comparable to my former salary as a pentester, I was quite satisfied considering my initial expectations. Stripe's program was generous, and the outcomes of my hunting were rewarding—both financially and in terms of knowledge gained.

I learned valuable lessons about program selection, noting that while I dedicated around 60 hours to Stripe.com without fruitful results after my initial findings, spending time on open-source assets was rewarding.

I believe this experience underlines the significant potential for payout within open-source components of programs and that future endeavors in bug hunting should perhaps focus more heavily in that direction.

If you want to dive deeper into my notes from this 100-hour challenge, remember that a portion of my documentation is available. Signing up for the BBR newsletter grants you access, and I assure you it will be well worth your time.

For my upcoming episode, I plan to focus on source code analysis, with a new target being Elastic.

Keywords

bug bounty, HackerOne, Stripe, vulnerabilities, pentester, payment provider, open-source, API, report, earnings, methodology.

FAQ

1. What was the primary goal of the 100 hours of bug bounty hunting?
The goal was to understand various flaws in an application rather than purely searching for bugs.

2. How many reports did you submit during the 100 hours?
I submitted three reports detailing vulnerabilities I discovered.

3. What was the total earning after completing the 100 hours?
The total earnings amounted to $ 3,100.

4. What were some of the key takeaways from your 100 hours of hunting?
Focus on the complexity of the target assets, consider the benefits of open-source assets, and prepare for periods of low motivation during the search process.

5. Will there be a follow-up to this bounty vlog?
Yes, after the reports are processed, I will be sharing insights in a second part via a live stream and will be addressing viewers' questions in real-time.