Uber Drivers Forum banner
1 - 8 of 8 Posts

·
Premium Member
Joined
·
275 Posts
Discussion Starter · #1 ·
I noticed this before and told Uber. When on a boost trip, get a ping- will show boost (looks like a surge). Do the ride to find out no surge. Contact help and they don’t see surge/boost, so no cash pal.

BUT IT SHOWED IN THE APP. Probably a mistaken variable call in the app.

Where do I collect my bug bounty?
 

·
Premium Member
Joined
·
998 Posts
Your bug is probably "Out of Scope" but you should read about Uber's bug bounty program yourself by going to this site:

https://hackerone.com/uber

Here is the current policy, copied from that site (some parts removed due to forum post length restrictions. Please click the link for the uneditted page)

Policy
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.

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. Prior bounty amounts awarded are not precedent for future payments.

In the same way that software is constantly changing, so will our program's scope in an effort to accurately represent the state of our services at that point in time.

Besides our scope, it's worth mentioning a few tenets of our program:

  • We expect respectful interactions, with researchers and our team treating each other as peers -- being willing to learn/teach and assuming best intents, always.
  • You can expect our team will assess impact of each report to determine maximum security impact, including transparency behind our reasoning and interpretation of impact.
Security Impact Buckets
Exposure of User Data: the ability to access user or employee data without having an authorized relationship from the Victim.

  • in-scope vulnerability class examples:
    • AWS Identity & Access Managementcredential exposure resulting in access to driver documents in an S3 bucket.
    • Adding a user to a Partner's account, without them accepting the invite, resulting in exposure of name, phone number, and trip history.
    • Password reset token exposure, allowing attacker the ability to reset password of victim and login to view sensitive user data.
    • IDOR/authorization vulnerabilities resulting in exposure of personal data.
  • out-of-scope vulnerability class examples:
    • The ability to determine if a phone number or email has an Uber account, also known as an account oracle.
  • potential domains to look at: auth.uber.com, partners.uber.com, riders.uber.com, eats.uber.com

Program Policies
  • 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.
  • Video only PoCs will not be considered.
  • Using duplicate HackerOne accounts is against our policy and can result in a program ban.
  • Currently, our program has zero trial reports for researchers with a signal of 1.0 or less.
  • A vulnerability must be reproducible for us to be considered in-scope.
  • Your participation in the Bug Bounty Program is voluntary and subject to the Bug Bounty Program Terms.
  • Please follow the Terms & Conditions of all of our in-scope domains.
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 Chuxing
    • uber.onelogin.com
    • OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them.
    • bizblog.uber.com
    • newsroom.uber.com
    • love.uber.com
    • drive.uber.com
    • eng.uber.com
    • people.uber.com
    • *.et.uber.com
Here is Uber's newsroom clip about it:
https://www.uber.com/newsroom/bug-bounty-program/

From that clip:
  • Uber has created a treasure map guide to show security researchers how to find the different classes of bugs across our codebase. This will be regularly updated.
 
1 - 8 of 8 Posts
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top