New Bug Bounty Treasure Map + Scope Update

Uber Security
Aug 16, 2017 · 3 min read

Lindsey Glovin, Program Manager, Product Security

When we launched our public bug bounty program in March 2016, we released a treasure map to tell researchers where to look for security bugs. Since then, feedback from researchers led us to commit to providing more resources like this.

Today, we’re excited to share the second generation of our bug bounty treasure map! This new version helps researchers find the most valuable treasure in our program: high impact security bugs.

We’re also introducing an updated program scope to better reflect the current state of Uber’s technical environment and the security vulnerabilities our bug bounty team cares the most about. This update focuses on defining the security impact of any given issue and will help researchers know which types of vulnerabilities are most important to our program (e.g. will receive the highest potential bounty).

Finally, we’re launching a complete reboot of our previous payment assessments to focus on what we care about most — the security of user data. As a result of these changes, the payment amounts of older reports should not be viewed as precedent for payments going forward.

Updated Program Scope

In the same way Uber’s code is constantly evolving, so will our bug bounty scope. We will continue to make updates as we learn more about our attack surface and roll out new protections.

Since launching our public bug bounty over a year ago, we now believe the traditional model of “domain + vulnerability class” is insufficient for determining bounties. For example, it’s not uncommon to reverse-proxy routes to a specific microservice, meaning an SSRF in partners.uber.com/profile versus partners.uber.com/documents can have different security impacts and therefore warrant different bounty amounts.

Additionally, if a microsite on a domain is not listed as in-scope but has a vulnerability that exposes user data, the traditional model would consider this out-of-scope. However, we care deeply about both of these situations. So, instead of making ongoing exceptions, we’re taking a more holistic approach to address the limitations of a traditional assessment model.

Specifically, we are moving to an updated scope guided by the upper bound of security impact for a report based on what the specific bug can do. As a result, researchers should expect bug assessments and bounty amounts to reflect security impact rather than technical complexity. We strongly suggest researchers explicitly connect the issues they discover into the defined security impact buckets within their report.

Below are more details on the security impact buckets that are now in-scope, along with specific vulnerability examples to illustrate our thinking.

The New Treasure Map: Security Impact Buckets

Helping researchers understand what’s most important to our bug bounty team is one way we hope to ensure the time spent looking for bugs on our platform is worthwhile. Our program guidelines page has the full details on how we define security impact buckets. Please check it out for specific examples of vulnerabilities that are or aren’t in-scope now.

Researchers are encouraged to focus on technical vulnerabilities from the categories below. Traditional social engineering, fraud (e.g. promo code abuse) and credential stuffing are still out-of-scope.

The Next Chapter

As we near 18 months since the launch of our public program, we’re increasingly grateful for the hundreds of researchers who participate and help us protect Uber users. We’ve paid more than $1M to date and we’re excited to work with you during this next chapter to continuously improve our program, find new ways to eradicate bugs from our codebase, and give back to the research community.

Uber Security + Privacy

Insights and updates from Uber’s security and privacy teams

Uber Security

Written by

Uber Security + Privacy

Insights and updates from Uber’s security and privacy teams