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

Summary

In this video, a bug bounty hunter documents their 100-hour challenge hunting vulnerabilities on Stripe's public Hackerone program. They explain their approach, methodology, and mindset, emphasizing the importance of understanding application flows rather than focusing solely on finding bugs. Over the course of the challenge, they report several vulnerabilities, earning $3,100 in rewards. The video details key moments of success, challenges faced, and lessons learned. The creator also shares their notes and methodology, and teases future content, including live streams and further bug bounty adventures.

Takeaways

• 🔍 The speaker spent 100 hours hunting bugs on a Stripe public bug bounty program from HackerOne.
• 💡 The goal was not to focus on finding bugs but rather to understand the different flows of the application.
• 💰 The speaker earned a total of $3,100 from three bug reports during the 100-hour challenge.
• 📉 The first bug was related to archived prices, allowing for a $31 price reduction, which was classified as a medium bug with a $1,000 payout.
• ⚙️ The second bug was found in a GitHub repository for Stripe’s API SDK, earning $500 and categorized as low severity.
• 💥 After 82 hours of bug hunting, the speaker found their biggest payout bug: $1,500, including a bonus for targeting a specific asset.
• ⏳ The speaker encountered long periods without finding bugs, especially during 60 hours spent on Stripe's main platform.
• 📄 Open source assets were identified as more productive for bug hunting than the main Stripe platform, suggesting future focus on those areas.
• 📊 The speaker emphasized the challenges in finding bugs on Stripe, noting that it is not as complex as platforms like Google.
• 🔗 The speaker shared their methodology and notes via a Notion page, with an invitation to join BBRE Premium for further insights and tips.

Q & A

What was the main objective of the 100-hour bug bounty challenge?

The main objective of the challenge was to understand different flows in the Stripe application and see if bugs would naturally emerge, as opposed to starting the challenge with the intention of finding bugs.

What platform was the bug bounty challenge conducted on?

The challenge was conducted on HackerOne, specifically targeting the Stripe program.

How did the speaker identify their first bug?

The speaker identified their first bug by testing archived prices in the Stripe payment flow. After switching between a new and old checkout link, they managed to purchase a service at an archived price.

How much was the speaker rewarded for their first bug, and what was its severity?

The first bug was classified as 'medium' severity, and the speaker was rewarded $1,000, which was the lower end of the range for medium-risk bugs on the Stripe program.

What kind of assets did the speaker focus on during the challenge?

The speaker focused on multiple assets within the Stripe program, including Stripe.com, the Stripe API, and open-source repositories related to Stripe on GitHub.

Why did the speaker continue with the challenge after 50 hours despite not finding more bugs?

The speaker considered stopping after 50 hours due to a lack of findings but decided to continue to complete the full 100-hour challenge for the sake of the experiment and the video they were creating.

What was the biggest payout the speaker received during the challenge, and for what bug?

The speaker’s biggest payout was $1,500 for a low-severity bug found in an open-source GitHub application. The reward included a $500 base payout and a $1,000 bonus because Stripe appreciated the speaker targeting that particular asset.

What did the speaker do after completing the 100-hour challenge in terms of reporting vulnerabilities?

After the 100-hour challenge, the speaker submitted one of their bugs a second time, claiming the fix for the original report was insufficient. The report was closed as a duplicate, but the speaker opened mediation to resolve the issue.

How does the speaker log working hours during the bug bounty challenge?

The speaker logs only the actual time spent working, excluding breaks, procrastination, and unrelated tasks, which means the 100 hours were spread over about three months but would equate to about one month of full-time work.

What were the key takeaways for the speaker after the 100-hour challenge?

The speaker realized that focusing on open-source assets was more rewarding than spending time on large platforms like Stripe.com. They also noted that despite finding some bugs, there were many missed opportunities, as bug hunting can be highly variable.