100 Days Into Uber Engineering’s Public Bug Bounty Program

Rob Fletcher, Collin Greene & Matthew Bryant
6 min readintermediate
--
View Original

Overview

Uber Engineering's public bug bounty program, launched in March 2016, has seen significant engagement from security researchers, resulting in over 2,000 reports and the identification of numerous security flaws. This article provides insights into the program's performance metrics, notable vulnerabilities discovered, and the ongoing commitment to improving security through community collaboration.

What You'll Learn

1

How to analyze the effectiveness of a bug bounty program using performance metrics

2

Why maintaining a healthy signal-to-noise ratio is crucial in bug bounty programs

3

How to identify and mitigate common web vulnerabilities like RCE and XSS

Key Questions Answered

What metrics indicate the success of Uber's bug bounty program?
Uber's bug bounty program has received 2,030 total reports, with a signal-to-noise ratio of approximately 1:6. The program has identified and fixed 161 security flaws, with a mean first response time of 23 hours and 51 minutes, and has paid out a total of $345,120.48 to researchers.
What notable vulnerabilities were discovered in the first 100 days?
Significant vulnerabilities included a Remote Code Execution via Jinja Template Injection, which was awarded $10,000, and a Cross-Site Scripting vulnerability on developer.uber.com, which earned $3,000. Additionally, a surge pricing bypass issue was reported, also valued at $3,000.
How does Uber handle duplicate reports in their bug bounty program?
Approximately 20% of the reports submitted to Uber's bug bounty program were duplicates. The program employs aggressive filtering and a well-defined scope to manage submissions effectively, ensuring that researchers focus on unique and impactful vulnerabilities.

Key Statistics & Figures

Total reports
2,030
Total number of bug reports submitted to the program
Security flaws found and fixed
161
Total number of identified and resolved security issues
Mean first response time
23 hours, 51 minutes
Average time taken to respond to a bug report
Total payout to researchers
$345,120.48
Total amount awarded to researchers for valid bug reports
Percentage of duplicate reports
~20%
Proportion of reports that were duplicates

Technologies & Tools

Template Engine
Jinja2
Used in the context of a vulnerability that allowed remote code execution
Bug Bounty Platform
Hackerone
Platform used to manage submissions and payouts for the bug bounty program

Key Actionable Insights

1
Implement a structured approach to triaging bug reports to improve response times and reduce duplicates.
By refining the submission process and utilizing tools like HackerOneAlchemy, organizations can enhance their bug bounty program's efficiency and effectiveness.
2
Encourage researchers to explore less obvious vulnerabilities that may not be covered by traditional security measures.
The surge pricing bypass example illustrates that valuable insights can come from creative approaches to testing, which may not be immediately apparent.
3
Regularly update the scope of the bug bounty program to focus on high-impact areas.
As demonstrated by Uber's decision to exclude WordPress sites from the scope, maintaining a clear focus helps maximize the program's effectiveness and resource allocation.

Common Pitfalls

1
Failing to adequately filter low-signal submissions can overwhelm the triage process.
Without effective filtering mechanisms, teams may struggle to identify legitimate vulnerabilities amidst a sea of low-quality reports, leading to resource drain and delayed responses.
2
Neglecting to update the program scope can lead to wasted efforts on low-impact areas.
As seen with Uber's exclusion of WordPress sites, regularly revisiting the scope ensures that researchers focus on the most critical services, maximizing the program's impact.

Related Concepts

Bug Bounty Programs
Web Application Security
Vulnerability Management
Remote Code Execution
Cross-site Scripting