Uber Bug Bounty Program Terms
The scope for Uber’s Bug Bounty Program is focused on securing the data of our
users. Therefore, our approach is to evaluate any given report based on the
specific security impact for users (versus domain + vulnerability class).
Below we describe the various security impact buckets that are in-scope,
examples of vulnerability types, and domains that could potentially have
meaningful security impact.
Your participation in our Bug Bounty Program is voluntary. By submitting a
report or otherwise disclosing a vulnerability to us (making a “Submission”),
you are indicating that you have read and agree to follow the rules set forth
on this page (“Program Terms”).
Ground Rules
- Research and disclose in good faith.
-
Respect our users’ privacy.
-
No extortion, shake downs, or duress.
- Don’t leave any system in a more vulnerable state than you found it.
- Don’t publicly disclose a vulnerability without our consent.
- Be respectful when interacting with our team, and our team will do the same.
Good Faith Vulnerability Research and Disclosure
You must act in good faith when investigating and reporting vulnerabilities to
us. Acting in good faith means that you will:
-
Play by the rules. This includes the Program Terms, Uber Terms of Use, and any terms and conditions for Uber’s in-scope domains. If there is any inconsistency between the these Program Terms and any of Uber’s other terms, these Program Terms will control.
-
Respect our users’ privacy. You should only interact with Uber accounts you own or with explicit permission from the account holder. We want you to hunt for bugs, not user data. If you encounter user information during the course of your research:
- Stop right there. Actions taken beyond this are not authorized.
- Report this immediately to our Bug Bounty team so we can investigate.
- Do not save, copy, store, transfer, disclose, or otherwise retain the information.
- Work with us if we have any further requests.
- Don’t extort us. You should never illegally or in bad faith leverage the existence of a vulnerability or access to sensitive or confidential information, such as making extortionate demands or ransom requests or trying to shake us down. In other words, if you find a vulnerability, report it to us with no conditions attached.
-
Don’t cause more harm than good. You should never leave a system or users in a more vulnerable state than when you found them. This means that you should not engage in testing or related activities that degrades, damages, or destroys information within our systems, or that may impact our users, such as denial of service, social engineering or spam.
If you have made a good faith effort to abide by these Program Terms, we will
not initiate or recommend legal action against you, and if a third party
initiates legal action, we will make it known that your activities were
conducted pursuant to the Bug Bounty Program.
Failure to act in good faith will result in immediate disqualification from
the Bug Bounty Program and ineligibility for receiving any benefit of the Bug
Bounty Program.
If at any point while researching a vulnerability, you are unsure whether you
should continue, immediately engage with our Bug Bounty team.
Eligibility to Participate
To be eligible to participate in our Bug Bounty Program, you must:
- Have a signal of at least 1.0 or written permission from Uber’s Bug Bounty Team.
- Be at least 18 years of age if you test using an Uber account.
- Not be employed by Uber or any of its affiliates or an immediate family member of a person employed by Uber or any of its affiliates.
- Not be a resident of, or make Submissions from, a country against which the United States has issued export sanctions or other trade restrictions.
- Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.
- Not be using duplicate HackerOne accounts.
If (i) you do not meet the eligibility requirements above; (ii) you breach any
of these Program Terms or any other agreements you have with Uber or its
affiliates; or (iii) we determine that your participation in the Bug Bounty
Program could adversely impact us, our affiliates or any of our users,
employees or agents, we, in our sole discretion, may remove you from the Bug
Bounty Program and disqualify you from receiving any benefit of the Bug Bounty
Program.
Security Impact Buckets
Exposure of User Data: the ability to access user or employee data without
having an authorized relationship with the Victim.
Unauthorized Requests on Behalf of User/Employee: the ability to forge
authenticated requests on the behalf of a Victim.
Monetary Impact: the ability to cause monetary impact to Uber or Uber
users through a technical vulnerability.
Phishing: (almost all examples of Phishing end up out-of-scope) the
ability to carry out targeted and convincing phishing on Uber users.
- in-scope vulnerability class examples:
- out-of-scope vulnerability class examples:
- Reports that do not demonstrate a technical vulnerability, like spear phishing.
- Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).
- potential domains to look at: uber.com, email.uber.com, riders.uber.com, partners.uber.com, eats.uber.com
Safety: the ability to bypass physical safety controls through a technical
vulnerability -- the key aspect of these reports is that there exists a
technical vulnerability in our services.
- in-scope vulnerability class examples:
- Trip rate IDOR authorization issue that allows a Driver to increase their rating.
- Ability to update driver image/documents without review from Uber.
- potential domains to look at: partners.uber.com, riders.uber.com
Calculating Security Impact
Understanding security impact of a given report is understanding which
security buckets it lands in, understanding the scale of exposure in each of
those situations, understanding what mitigating factors exist, and finally
understanding what multiplying factors exist. Below are some categories to
consider when assessing security impact.
Multiplying Factors
- sensitivity of user data exposed -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.
- scale of exposure -- when considering security impact of any given vulnerability, it’s important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.
- severity of forged actions -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user’s last name versus their bank account number have drastically different security impacts.
- forge communication from Uber -- when a vulnerability allows an Attacker to send communication (and control the content) to a Victim and have it come officially from Uber. An example would be the ability to control the contents of an in-app push notification.
Mitigating Factors
- requires user interaction -- when an exploit scenario requires a human from Uber or a Victim to manually interact before exploit is successful.
- authorized relationship -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.
- requires brute forcing -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how “hard” it is to brute force the value in question -- brute forcing phone numbers is much “easier” than a UUID.
- existence of rate limiting -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be “mitigating” factor since it doesn’t require actually having unique IPs.
- physical access -- exploit scenarios requiring physical access to a device.
- noticeable to victim -- exploits that are noticeable to victim. For example, changing someone’s password on their account would lock them out of their account and would be immediately noticeable.
- account put into arrears or banned -- when an exploit then puts the Attacker’s account into arrears or results in a ban.
- social engineering -- when an exploit requires social engineering a person to be successful.
- requires privileged network position -- when an exploit (often times MiTM) requires having privileged network position to be successful
- requires multiple accounts -- when an exploit requires the ability to mint new accounts indefinitely.
See our recent blog post __on Treasure Map 2.0 for some specific
examples on determining security impact of a given report.
Submissions and Report Quality
High quality Submissions allow our team to better understand the issue and
relay the bug to the internal team to fix. The best reports provide enough
actionable information to verify and validate the issue without any follow up
clarifying questions.
- Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.
- Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).
- Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don’t have evidence and a mutual understanding of security impact.
- In some cases, it may not be possible to have all of the context on the impact of a bug. If you’re unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.
- Video only proof-of-concepts (PoCs) will not be considered.
- A vulnerability must be verifiable and reproducible for us to be considered in-scope.
Confidentiality
Any information you receive or collect about us, our affiliates or any of our
users, employees or agents in connection with the Bug Bounty Program
(“Confidential Information”) must be kept confidential and only used in
connection with the Bug Bounty Program. You may not use, disclose or
distribute any such Confidential Information, including without limitation any
information regarding your Submission, without our prior written consent. You
must get written consent by submitting a disclosure request through the
HackerOne platform.
Report States
We strive to be consistent with how we close reports and below are the details
for each state:
- spam -- a report with no useful information
- needs more info -- not enough actionable information in report to triage
- not applicable -- no reproducible security vulnerability or explicitly out-of-scope per our guidelines
- duplicate -- a vulnerability that has previously been found either internally or via Hackerone
- informative -- a reproducible issue with negligible security impact or an issue with a product that doesn 't affect our service/software (e.g. an S3 bucket named uber-secret-stuff that isn't actually related to us)
- triaged -- either a valid report or a report that needs more investigation from an internal team, typically the former
- resolved -- a verified vulnerability that has been fixed
Bounty Amounts
Previous bounty amounts are not considered precedent for future bounty amounts
-- software is constantly changing and therefore the given security impact of
the exact same issue at different times in the development timeline can have
significantly different security impacts.
Bounty awards are not additive and are subject to change as our internal
environment evolves. We determine the upper bound for security impact and
award based on that impact.
We focus bounty amounts on the security impact of any given issue -- things
that influence security impact are the scale of exposure and the various
mitigating and multiplying factors.
We recognize that researchers value receiving bounties sooner than later, but
basing payouts on security impact often requires us to get to resolution
before we completely understand the potential security impact. To accomplish
both of these needs, we have a hybrid model where we pay out our minimum
bounty at time of triage and then full bounty at resolution once we completely
understand security impact.
The general process for determining bounty:
- Determine which security impact buckets the issue falls in. It’s likely that any given issue will land in several different impact buckets -- we choose the most impactful and severe bucket. We try to answer the question “What is the most damaging thing you could do with this issue?”
- Determine the approximate scale of exposure to try and answer “how many users could be exploited by an Attacker?”
- Determine mitigating factors that reduce the security impact of different issues -- this often involves asking “What could make this vulnerability hard to exploit?” or “How sensitive are the things being changed/accessed by the vulnerability?”
- Determine multiplying factors that increase the security impact of different issues -- this also often involves asking “How sensitive are the things being changed/accessed by the vulnerability?” or “What other exposure exists that the researcher didn’t explicitly call out?”
- With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount.
The bounty ranges for the different security impact buckets:
- Exposure of User Data -- the payout ranges for this bucket range from $0 to $10,000.
- Unauthorized Requests on Behalf of User/Employee -- the payout ranges for this bucket range from $0 to $10,000.
- Monetary Impact -- the payout ranges for this bucket range from $0 to $10,000
- Phishing -- the payout ranges for this bucket range from $0 to $5,000
- Safety -- the payout ranges for this bucket range from $0 to $10,000
Bounty payouts and amount, if any, will be determined by us in our sole
discretion. In no event are we obligated to provide a payout for any
Submission. The format, currency and timing of all bounty payouts shall be
determined by us in our sole discretion. You are solely responsible for any
tax implications related to any bounty payouts you may receive.
If we receive several reports for the same issue, we offer the bounty to the
earliest report for which we had enough actionable information to identify the
issue.
Out-of-Scope
- Vulnerabilities whose primary security impact is focused on Phishing in a domain that is not in one of our primary domains (e.g. www.uber.com __, riders.uber.com, partners.uber.com, login.uber.com, auth.uber.com, eats.uber.com, rush.uber.com, developer.uber.com).
- UUID enumeration of any kind.
- Invite/Promo code enumeration.
- Account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an Uber account exists.
- Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.
- Reports that state that software is out of date/vulnerable without a proof-of-concept.
- Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, Edge, IE and the versions of our application that are currently in the app stores.
- Stack traces, path disclosure, and directory listings.
- CSV injection.
- Best practices concerns.
- Highly speculative reports about theoretical damage -- please always provide a proof-of-concept.
- Vulnerabilities that cannot be used to exploit other users or Uber -- e.g. self-xss or having a user paste JavaScript into the browser console.
- Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.
- Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.
- Distributed denial of service attacks (DDOS).
- Physical or social engineering attempts (this includes phishing attacks against Uber employees).
- Content injection issues.
- Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)
- Missing cookie flags on non-authentication cookies.
- Issues that require physical access to a victim’s computer/device.
- SSL/TLS scan reports (this means output from sites such as SSL Labs).
- Banner grabbing issues (figuring out what web server we use, etc.).
- Open ports without an accompanying proof-of-concept demonstrating vulnerability.
- Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry raccoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted.
Out-of-scope domains
*.uber.com.cn domains or any other properties relating to Uber in China, since they belong to Didi Chuxinguber.onelogin.com
- OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.
bizblog.uber.comnewsroom.uber.comlove.uber.comdrive.uber.comeng.uber.compeople.uber.com*.et.uber.com
Rights and Licenses
We may modify the Program Terms or cancel the Bug Bounty Program at any time.
By making a Submission, you represent and warrant that the Submission is
original to you and you have the right to submit the Submission.
By making a Submission, you give us the right to use your Submission for any
purpose.
Uber
