└── README.md /README.md: -------------------------------------------------------------------------------- 1 | (This project is deprecated and not maintained.) 2 | 3 | # Scope 4 | 5 | We are interested in any vulnerability that could negatively affect the security of our users. 6 | 7 | ## In-Scope Vulnerability Classes 8 | * Cross-site Scripting (XSS) 9 | * Cross-site Request Forgery 10 | * Server-Side Request Forgery (SSRF) 11 | * SQL Injection 12 | * Server-side Remote Code Execution (RCE) 13 | * XML External Entity Attacks (XXE) 14 | * Access Control Issues (Insecure Direct Object Reference issues, etc) 15 | * Exposed Administrative Panels that don't require login credentials 16 | * Directory Traversal Issues 17 | * Local File Disclosure (LFD) 18 | 19 | ## In-Scope Properties 20 | * api.uber.com 21 | * bonjour.uber.com 22 | * business.uber.com 23 | * cn-cfe1.uber.com 24 | * cn-dc1.uber.com 25 | * cn-dc2.uber.com 26 | * cn-dc3.uber.com 27 | * cn-dca1.uber.com 28 | * cn-geo1.uber.com 29 | * cn-pek1.uber.com 30 | * cn-pr.uber.com 31 | * cn-sjc1.uber.com 32 | * cn-slow1.uber.com 33 | * cn-slow2.uber.com 34 | * cn-slow3.uber.com 35 | * cn-spdy.uber.com 36 | * cn-tt1.uber.com 37 | * cn.uber.com 38 | * cn1.uber.com 39 | * cnfrontend-dca1.uber.com 40 | * cnfrontend-sjc1.uber.com 41 | * cnfrontend.uber.com 42 | * csp.uber.com 43 | * developer.uber.com 44 | * dial.uber.com 45 | * eats.uber.com 46 | * get.uber.com 47 | * getrush.uber.com 48 | * help.uber.com 49 | * login.uber.com 50 | * lert.uber.com 51 | * m.uber.com 52 | * partners.uber.com 53 | * petition.uber.org 54 | * riders.uber.com 55 | * rush.uber.com 56 | * sftp.uber.com 57 | * sms.uber.com 58 | * track.uber.com 59 | * trip.uber.com 60 | * ubereats.com 61 | * ubermovement.com 62 | * \*.uberinternal.com 63 | * vault.uber.com 64 | * www.uber.com 65 | * Android/iPhone Partner App 66 | * Android/iPhone Rider App 67 | * Android/iPhone Eats App 68 | 69 | ## Out-of-scope Vulnerability Classes 70 | * 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. 71 | * Publicly accessible login panels - These generally have low security impact and are in software that Uber runs but doesn’t control. 72 | * Reports that state that software is out of date/vulnerable without a proof of concept. 73 | * Host header issues without an accompanying proof-of-concept demonstrating vulnerability. 74 | * XSS issues that affect only outdated browsers. 75 | * Stack traces that disclose information. 76 | * CSV injection. Please see [this article](https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection). 77 | * Submissions on the S3 bucket `uber`, **We do not own this bucket!**. 78 | * Best practices concerns. 79 | * Highly speculative reports about theoretical damage. Be concrete. 80 | * Self-XSS that can not be used to exploit other users (this includes having a user paste JavaScript into the browser console). 81 | * Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue. 82 | * Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated. 83 | * Denial of Service Attacks. 84 | * Reflected File Download (RFD). 85 | * `window.opener`-related issues. 86 | * Physical or social engineering attempts (this includes phishing attacks against Uber employees). 87 | * Content injection issues. 88 | * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.) 89 | * Missing autocomplete attributes. 90 | * Missing cookie flags on non-security-sensitive cookies. 91 | * Issues that require physical access to a victim’s computer. 92 | * Missing security headers that do not present an immediate security vulnerability. 93 | * Fraud issues (please see the below section elaborating on this). 94 | * SSL/TLS scan reports (this means output from sites such as SSL Labs). 95 | * Banner grabbing issues (figuring out what web server we use, etc.). 96 | * Open ports without an accompanying proof-of-concept demonstrating vulnerability. 97 | * Recently disclosed 0day vulnerabilities. We need time to patch our systems just like everyone else - please give us two weeks before reporting these types of issues. 98 | * Entering the Uber offices, throwing crisps everywhere, unleashing a bunch of hungry racoons, and hijacking an abandoned terminal on an unlocked workstation while staff are distracted. 99 | 100 | ## Out-of-scope Properties 101 | * uber.onelogin.com 102 | * OneLogin runs their own bug bounty program and any vulnerabilities for OneLogin should be reported to them. 103 | * \*.dev.uber.com 104 | * \*.dev.uberinternal.com 105 | * brand.uberinternal.com 106 | * \*.et.uber.com - The underlying software here is exacttarget which Uber does not have control over. 107 | * uber-finder.com - this is not software owned by Uber Engineering. 108 | 109 | # Rewards 110 | 111 | Our rewards are impact-based. This means, for example, that we will issue a relatively high reward for a vulnerability that has the potential to leak sensitive user data, but that we will issue little to no reward for a vulnerability that allows an attacker to deface a microsite. When we have our reward meetings, we always ask one question: If a malicious attacker abuses this, how bad off are we? We assume the worst and pay out the bug accordingly. 112 | 113 | 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. We don't want to encourage people spamming us with vague issues in an attempt to be first. 114 | 115 | If a single fix fixes multiple vulnerabilities, we treat this as a single vulnerability. For example, if you find 3 vulnerabilities in a WordPress plugin we use, and our fix is to remove the plugin, this will receive a single bounty, determined, as always, by impact. 116 | 117 | The payout ranges on this page are guidelines to express roughly how we think about the severity of classes of issues. They are not exact rules. There can be attributes of bugs that make them more or less severe, which will affect the payout. For example, if a vulnerability affects only a small population of users, it will likely receive a lower reward than a similar vulnerability that affects a larger population of users. To date, we have most commonly rewarded on the top end of our published payout ranges. 118 | 119 | At the end of the day, all reward amounts are at our discretion, but we aim to be fair. Some researchers won't agree with some of our decisions, but we're paying out to the best of our ethical ability and trust that the majority of researchers will consider their rewards fair and in many cases generous. We will adapt as the program continues. 120 | 121 | ## Things you should expect to receive little to no bounty for 122 | * Microsites with little to no user data 123 | * Issues requiring user-interaction 124 | * Outdated wordpress instances 125 | * Most brute forcing issues 126 | 127 | ## Bounty Payout Range 128 | N.B: the amounts listed here are the maximum we can pay for these categories of issues. This is meant as rough guidance on how we think about rewarding issues, ultimately we will reward largely based on the impact of the issue but at our discretion. 129 | 130 | * **Critical issues ($10,000)** - Remote code execution on a production server. Exposure of information that identifies individuals (social security numbers, credit card numbers, bank account numbers, driver license images) Full account takeover of rider/partner account without interaction. Payment or partner invoice information exposure at scale. Potential access to source code. XSS in Toolshed (our internal account management system), or server-side request forgery (SSRF). Vulnerabilities leading to the compromise of an employee account (with a way to bypass two-factor). 131 | 132 | * **Significant Issues ($5,000)** - Stored Cross-site Scripting which can cause significant brand damage (e.g. in a homepage), missing authorization checks leading to the exposure of email addresses, date of birth, names, phone numbers, etc. 133 | 134 | * **Medium Issues ($3,000)** - Reflected Cross-site Scripting (XSS), most Cross-site Request Forgery (CSRF) issues, access control issues which do not exposed PII but affect other accounts, some account validation bypasses (being able to change driver picture, etc). Any vulnerability which allows the bulk lookup of user UUIDs (e.g. turn an auto-incrementing ID into a UUID, turn an email into a UUID). 135 | 136 | * **Fraud Issues** - Send these to `ext-uber-fraud@uber.com`. We currently do not reward for fraud issues. 137 | 138 | # Miscellany 139 | 140 | ## Reporting Guidelines 141 | We need detailed written steps to reproduce. We do not accept reports that include only a video. 142 | 143 | ## Policy Changes 144 | You can view the changes to this policy over time at [hackerone.com/uber/policy_versions](https://hackerone.com/uber/policy_versions). 145 | 146 | ## Fraud issues 147 | If you’d like to report an issue related to fraud, please contact ext-uber-fraud@uber.com. These type of issues are important but we unfortunately cannot reward issues if this type at this time. Specifically promo code fraud and give-get fraud is abuse of our promotional offers and referral codes in order to get free rides from Uber are a common submission. We do not consider these in scope for our bug bounty program at this time unless they show an explicit technical vulnerability in our software. Lack of verification for things such as phone numbers, credit cards, etc are all fraud related issues and are not in scope for this bug bounty program. 148 | 149 | ## Examples of good bugs 150 | * https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/ 151 | * http://blog.portswigger.net/2016/04/adapting-angularjs-payloads-to-exploit.html 152 | * http://blog.orange.tw/2016/04/bug-bounty-uber-ubercom-remote-code_7.html 153 | * https://labs.integrity.pt/articles/uber-hacking-how-we-found-out-who-you-are-where-you-are-and-where-you-went/ 154 | 155 | # Frequently Asked Questions 156 | 157 | ## Can I blog about my bug? 158 | Yes, but we ask that you wait until the issue is both fixed and paid out before you publish the blog post. We also prefer that you request disclosure through HackerOne so that readers of your blog post can get the full background on the issue. 159 | 160 | ## What is your policy on chaining bugs and privilege escalation? 161 | Chaining of bugs is not frowned upon in any way, we love to see clever exploit chains! However, if you have managed to compromise an Uber-owned server we do not allow for escalations such as port scanning internal networks, privilege escalation attempts, attempting to pivot to other systems, etc. If you get access to an Uber server please report it us and we will reward you with an appropriate bounty taking into full consideration the severity of what could be done. Chaining a CSRF vulnerability with a self XSS? Nice! Using AWS access key to dump user info? Not cool. 162 | 163 | ## Do you provide test accounts? 164 | As of this time we do not have a good system for creating test accounts for our bug bounty submitters. Please create an account as you would normally and perform testing with that account or accounts. Whenever possible only test against yourself, never other users. If there is ever a situation where you cannot test a bug while adhering to this please let us know and we will help figure out an appropriate solution. 165 | 166 | ## What is a user UUID and when do you reward for enumeration of it? 167 | We reward for issues which allow you to enumerate bulk user UUID's via a phone number or email address. For example, if there's an endpoint that allows you to submit an email and the response contains that user's UUID - this is a vulnerability we would reward for. To verify this you should compare the UUID you're seeing with your own email. To get your personal account UUID visit `help.uber.com` after authenticating and copy and paste the following JavaScript in your browser's developer console: 168 | ```js 169 | alert(JSON.parse($("#web-support-data-script").text).user.uuid); 170 | ``` 171 | (We reward for this bug because we want to make it harder to perform bulk insecure direct object reference attacks against our users). 172 | 173 | ## What is a vehicle UUID and when do you reward for enumeration of it? 174 | A vehicle UUID uniquely identifies a vehicle within our systems. Any instance where you could collect a lot of vehicle uuids is probably interesting to us, depending on the circumstances. 175 | To get a list of your vehicle UUIDs, navigate to https://partners.uber.com/vehicles/ and paste the following into your browser’s development console: 176 | ```js 177 | vuids = document.querySelectorAll( "#vehicle-uuid" );for( var i = 0;i