Uber Engineering Bug Bounty: The Treasure Map

Today we launched our public bug bounty program at Uber. Embarking on a new bug bounty program can be difficult; it takes time for security researchers to learn the systems, the architecture, and the types of vulnerabilities likely to be lurking. To help you with this quest, Uber’s engineering security team has assembled this treasure map of various services at Uber and tips for uncovering security issues.

There are many moving parts that make up the service we call Uber. Peruse this short list of our public-facing services for some information about how they work along with some bug hunting tips for each.

What it does: The Uber iOS and Android apps communicate with this service while you use Uber. Tons of functionality is exposed here—everything from finding nearby drivers to splitting trips with your friends. This API exposes the largest attack surface of any service here at Uber.

What to look for: Much like our external API, cn.uber.com is a RESTful API performed over certificate-pinned HTTPS requests. The best way to hunt for bugs here is to use your own token via the X-Uber-Token header, use the UUID of another trip/user/resource, and see if the request succeeds (basically, perform access control testing). Keep in mind that you should only ever perform this testing against accounts you own (failure to do so could result in removal from the program, which nobody wants!).

What it runs on: Because this service acts as a gateway proxy to many of our services, frameworks and languages vary.

What it does: This is where partners enter bank information and their national ID number so that 1) they can get paid for their work and 2) we can run them through our screening process.

What to look for: The name of this site alone should excite many bug hunters to hack here. Any web or access control vulnerabilities are very high-risk issues and will receive appropriate payout. We are especially interested in vulnerabilities that could allow an attacker to bypass the SMS verification system for modifying Vault information for a partner account.

What it runs on: Flask, Jinja2, React, and Flux.

What it does: Uber for Business lets businesses manage rides for their employees conveniently.

What to look for: In addition to the regular web vulnerability concerns, any vulnerability that would allow for a limited employee account to perform an administrator-only action is a concern. For example, if an employee is able to change organizational settings without being an administrator, we need to catch that.

What it runs on: React and Express.

What it does: Uber driver partners visit this website to manage their account information. Sensitive information—private driver documents, payment statements, tax information—lives here.

What to look for: Access control vulnerabilities are a major concern, so for anything that could expose a driver partner’s private information, you can expect a large reward. Any web vulnerability that could allow the hijacking of a user’s account is also considered high risk.

What it runs on: Flask, Jinja2, React, and jQuery.

What it does: This external API allows people to build awesome apps that interact with Uber in creative ways.

What to look for: Also includes api.uber.com and sandbox-api.uber.com. Our major concerns for the API revolve around proper access restrictions. Third-party apps should only be able to access Uber account information if the user has consented to it. Users see a prompt that states which information the third-party app will use and asks for confirmation. We want to uncover any deviations in scope. For example, if a user gives a third-party app consent to pull their profile information, but trip information is also able to be pulled, that’s scope creep that warrants a reward. Other interesting areas are vulnerabilities in the OAuth flow that occur when a user allows an app to access their account information.

What it runs on: developer.uber.com: Node.js and React. api.uber.com: Python.

What it does: This website is where Uber riders can log in and view their past trips, change their profile and payment information, and find lost items.

What to look for: For this service, all web vulnerabilities are a concern as well as any bug that could result in disclosure of arbitrary Uber rider information. This relatively small app houses important functionality, such as the ability to view trip history and modify payment details.

What it runs on: Node.js, Express, and Backbone.js.

What it does: The various Uber apps that riders and driver partners use are by far the most common way that people interact with Uber.

What to look for: Try to find mobile-app-specific vulnerabilities, such as insecurely exposed Android intents, insecure storage of information, and embedded credentials stored in source code that yield access to sensitive information.

What it runs on: The mobile applications are some of the most dynamic projects here at Uber. The frameworks and libraries vary greatly.

What it does: The Uber help website allows driver-partners and riders to search our knowledge base and submit new support requests for issues they may be experiencing.

What to look for: Since this service allows for partners and riders to submit support tickets, any web vulnerabilities, such as cross-site scripting (XSS) or cross-site request forgery (CSRF) that could force a support ticket to be submitted on behalf of another user are considered high risk.

What it runs on: Node.js, Flux, and React.

The ability to turn emails into user UUIDs in bulk

This issue is one that’s unique to Uber. We are interested in any way an attacker could look up arbitrary user UUIDs in bulk. If you find a way to do this, we consider this vulnerability as great as any other and will pay for it.

Enumeration of business sensitive information

Uber is interested in any place where business information is leaked. If our software leaks information—how many users we have, how many trips we do, or any other similar information—we want to fix it. Common causes of these leaks are auto incrementing IDs, which expose how many entries are in a database and thus leak the number of potential users, trips, orders, etc. Endpoints without proper rate limiting could also leak business data by allowing someone to constantly monitor active driver activity, for example.

For a list of vulnerabilities outside of this bounty program’s scope, please see our HackerOne bug bounty page.

Go to our official bug bounty page to get started!

By Matthew Bryant, Uber application security software engineer, with Collin Greene, engineering manager of the Uber Product Security Team. Visit our Careers Page for more application security and engineering security openings.

Photo Credits for Header: “Bug” by Henri Sivonen, licensed under CC-BY 2.0. Image cropped for header dimensions and color corrected.

Treasure Map Image Credit (for subsequent ASCII conversion): Map Scroll Pirate Treasure, licensed under CC0 1.0 Public Domain.

Like what you’re reading? Sign up for our newsletter for updates from the Uber Engineering blog.