Recap: H1–4420 Live Hacking Event

Lindsey Glovin, Bug Bounty Manager, Application Security

On June 7th, 2019, Uber ran its third live hacking event in partnership with HackerOne. We also ran our first mentorship day to teach hacking skills to women from the security community, pairing them with experienced mentors to guide them in finding vulnerabilities on the Uber platform, answer questions, and help unblock them if they got stuck along the way.

This event was our most successful yet and resulted in:

• 140+ valid reports
• $375K+ total bounties paid

Of course, we’re always looking for ways to improve despite this success, so we’re passing along key takeaways and recommendations for other bug bounty programs considering live hacking events down the road.

Pre-submissions were a WIN

H1–4420 was the first time we accepted submissions from researchers ahead of a live hacking event. We opened submissions roughly 2 weeks before the event after our initial scope call with the researchers, so they were able to get to work immediately. The findings during this time period exceeded our expectations, both in terms of quantity and quality, resulting in the need to triage reports during a US holiday weekend. This created significantly more work for our security team on-calls, and we suggest other bug bounty programs be mindful of the timing of their event, and consider having extra on-call coverage not just during the event, but during the pre-submission period as well.

During the pre-submission phase, we received 110 valid reports, out of 146 total valid reports from the whole event. That means 75% of the reports we triaged for H1–4420 came in before the day of the live event, a valuable opportunity we will look to repeat when we plan future events.

If you’re considering accepting pre-submissions for your next live hacking event, it’s very helpful to validate all pre-submission reports before the event, with a suggested bounty amount and internal team assignments for triage. Pull in other security team members to help with the workload if needed. Don’t underestimate how busy your bug bounty team will be during the event. The more you can complete ahead of time, with support from the broader team, the better.

Prepare internal teams

This live hacking event was focused on a few specific targets, but we received reports about many other assets. These researchers are good at what they do, and you don’t want to catch other internal teams off guard with alerting, escalations at odd hours, and a high volume of vulnerabilities to triage. Preparing internal teams and ensuring all teams have secondary oncalls set up is paramount to your success, particularly when running an event with international time zones.

Make your scope crystal clear

It’s vitally important to ensure that researchers understand the scope of your bug bounty program and what you are looking for ahead of time. This makes it easy for researchers to understand what you consider to be impactful, and therefore, where to focus their time. The scope of the overall program should be included on the event scope page and presented to researchers during the scope call.

Your out of scope list should be comprehensive as well — the less you have to clarify in responses to out of scope reports, the more time you have to handle more important things the day of the event. A clear scope also helps reduce bounty disputes during and after the event, giving your team and the researchers more time to focus on finding and fixing bugs.

Bounties!

Aside from determining bounties for pre-submission reports ahead of time, it’s a good idea to have a matrix or bounty table to follow before/during/after the event. If you have an elevated bounty table for the event, make sure you have done your budget calculations ahead of time and have enough balance in your account to handle the increased awards from the event.

As always, it’s important to stay consistent with your payouts. Even more than usual, researchers at live events share bounty amounts and report details, so be as proactive and transparent as you can be about these decisions. Things move extremely fast at live events and time flies by, so it can be hard to keep up if you don’t have a clear matrix for your team to follow.

It takes a village

Depending on the size of your current bug bounty team, it’s likely you will need help with pre-submission validation, triage, and bounty determination before, during, and after the event. Ahead of the event, if you receive a large volume of reports, you may need to loop in other team members to handle the work.

Providing clear instructions on what exactly these team members need to do is important, especially if they don’t normally perform these types of tasks. Consider creating a playbook that everyone can follow for creating internal tasks, determining report severity, adding suggested bounty amounts to reports, and getting everyone invited to the appropriate event instance, communication channels, etc.

It’s also a good idea to have a designated role for everyone helping with the event. We normally have designated team members assigned to researcher questions, helping with triage questions, responding to and escalating critical reports, determining bounty amounts, and mentoring new bug hunters.

Be prepared for higher volumes of post-event work as well, especially if the event was successful in helping you find a lot of good bugs. Triaging all the reports, follow-up with researchers, resolving bounty disputes, clearing report queues, and escalation post-mortems can seem overwhelming if you’re not ready in advance. We looped in our entire AppSec team to help with the load, which eased the burden on the bug bounty team after a busy and productive event in London.