The last time Hackerfall tried to access this page, it returned a not found error. A cached version of the page is below, or clickhereto continue anyway

How I Got Paid $0 From the Uber Security Bug Bounty

How I Got Paid $0 From the Uber Security BugBounty

[.jp translation]

So Uber partners with HackerOne to offer a public bug bounty program, advertising a $500 minimum guaranteed payout if a security vulnerability is found within an Uber app or information asset. Fair enough, Ive led numerous penetration tests over the years in addition to delivering advanced pentest training for corporate clients.

I spent a few days getting some resources lined up for the analysis piece, and built a fairly comprehensive map of Ubers various endpoints using subdomain enumeration and application fingerprinting. I also start kicking the tires of Ubers Android app, which is locked down pretty tight per the Uber Bug Bounty Treasure Map with certificate-pinned HTTPS requests. After a few hours of wrangling with the Android SDK, I get the most recent Uber.apk running in an ARM emulator as they apparently dont publish any x86 Android apps. Slooooooow progress to say the least.

I manage to bypass some of the certificate pinning security in the Uber.apk, sufficient to start mapping out some of the Uber mobile endpoints. There is reference in that traffic to a Microsoft Phone API, so I head over to the Microsoft Store and start testing the Uber Surface/Windows Phone app.

It doesnt implement any type of certificate pinning, which is a violation of Ubers own publicly-stated Treasure Map; so theres the first guaranteed $500 payout per their bug bounty.

Uber uses OAuth2 tokens for all of their mobile app authentication workflow, which has a lot of security benefits over old school cookie-based authentication methods. I put together a Python-based client that can talk to Ubers backends to start harvesting OAuth2 tokens, but whats weird is the OAuth2 token doesnt ever change, and I cant find anything in the Uber developer documentation that deals with token expiration; literally the same token I was issued when I first created my Uber account for testing is the same token I keep getting, no matter how many times I log in and out of my account using the Surface app. Surely Uber is expiring these tokens at least once every few days?

I put that issue on the back burner and start probing the Uber promo endpoint, which has two pretty glaring vulnerabilities in that it doesnt implement any type of rate limiting for promo code POSTs nor does it require any multifactor authentication. Or in other words, I can fire up an HTTP load testing suite to issue thousands of promo code POSTs to this endpoint, to enumerate OAuth2 tokens; in a few minutes I am able to enumerate over a million OAuth2 tokens, without any type of IP blacklisting or rate limiting taking place.

Back to the token expiration issue. This Surface app doesnt actually communicate with the Uber backend whenever it processes a logout event, and I am able to access all Uber rider endpoints using my OAuth2 token even after the Surface app logs off. Huh?

So Uber is processing mobile app logouts locally, without any type of token expiration or invalidation taking place. Thats a big one, and now I understand why there is no mention made to OAuth2 token expiration in any of the Uber developer documentation: because once a user creates an account with Uber, the OAuth2 token thats issued never expires and their mobile applications only process logout events locally in the client itself. This is a big application security No No that maps to several public CVE and OWASP vulnerability definitions, so I submit the first round of these issues to HackerOne for payment.

Issue 1: The Uber Customer Promo Endpoint does not implement multi factor authentication resulting in the ability of an attacker to enumerate millions of OAuth2 rider and driver tokens.

Issue 2: The Uber Customer Promo Endpoint does not implement any type of rate limiting and/or IP address blacklisting resulting in the ability of an attacker to enumerate millions of OAuth2 rider and driver tokens.

Issue 3: The Uber Microsoft Surface/Phone app does not implement certificate pinning in addition to accepting self-signed certificates in violation of the cn.uber.com is a RESTful API performed over certificate-pinned HTTPS requests required by the Uber Bug Bounty Treasure Map.

Issue 4: Uber mobile apps are only processing logout events locally, resulting in OAuth2 tokens never being expired and with the ability to access driver and rider information after a user has logged out of their Uber mobile app.

So these tickets get assigned to Rob Fletcher with Ubers security team.

Issue 1: Uber knows about this problem, we are going to fix it in the future. No payout.

Issue 2: Uber knows about this problem, we are going to fix it in the future. No payout.

Issue 3: Uber knows about this problem, we are going to fix it in the future. No payout.

Issue 4: Uber does not currently have the ability to expire issued tokens. We are going to address this issue with our next generation authentication framework. No payout.

At this point Ive spent over a week of my time on this bug bounty that has a clearly stated $500 minimum payout policy; not one of these issues have been publicly documented as out-of-scope on Ubers Bug Bounty Treasure Map and/or the HackerOne Uber Bug Bounty disclosure page; and, with the certificate pinning vulnerability directly contradicting the requirements of Ubers Bug Bounty Treasure Map itself?

So I file a mediation request with HackerOne. It gets assigned to Kevin Rosenbaum. His response:

I am sorry you are having a negative experience with this issue, but we have contacted the Uber App Sec team and they have confirmed with us that these are not security issues that are in scope on their program. I understand that this can be a disappointment but I can assure you that they looked at this report and gave it the proper attention it deserved. I hope you can continue to work on our site and I wish you the best of luck.

OK. Now I am determined to demonstrate a critical severity vulnerability that Uber cant get around. Its obviously open mic night in their infosec department, and I bet I can hammer them with something that they cant dismiss as vaguely out of scope.

Another day of digging around and I can reflect query parameters from the https://m.uber.com mobile endpoint. Their Content Security Policy includes a whitelist for *.cloudfront.net. I can enable Cloudfront in my Amazon Web Services console and host whatever arbitrary JavaScript code I want there, to be executed by https://m.uber.com. These are two separate issues considered critical severity findings under Content Security Policy 3, in addition to the ability to reflect arbitrary whatever through their mobile endpoint.

I submit the report to Uber:

The udi-id request parameter at the https://m.uber.com/0-dfffb25d2cf6ceeb0a27.js mobile endpoint is copied into a javascript string encapsulated in double quotation marks, resulting in SSL-protected payloads being reflected unmodified in the applications response. The script-src whitelist at the endpoint includes a wildcard *.cloudfront.net host, which could be used by any attacker with an Amazon Web Services account to provision an arbitrary cloudfront.net host to serve trusted files from. The endpoint also has a missing base-uri, which allows the injection of base tags. They can be used to set the base URL for all relative (script) URLs to an attacker controlled domain. In addition to the reflected XSS issue, both the script-src and base-uri issues are considered high severity findings under Content Security Policy 3.

Im also able to bypass the Uber OneLogin SSO portal, resulting in source code disclosure from their internal uChat employee messaging system. Its not as serious as the XSS/CSP issues, but I throw that in a second report for good measure.

Rob Fletcher gets assigned the ticket:

Well take a look into this one more time, but so far this is not a security bug that is in scopeyouve failed to demonstrate Javascript execution in a modern browser and the other behavior you allude to with generating some arbitrary text using single quotes sounds like simple content injection, which is out of scope for our program.
Please refrain from making theoretical arguments for why something has security impact and instead familiarize yourself with our scope page and demonstrate actual security impact that is in scope per our guidelines.

Ok. So Ive demonstrated reflected XSS through their mobile endpoint, but their WAF is apparently filtering double quotes to prevent arbitrary JavaScript execution, and Uber is attempting to constrain the definition of XSS to only JavaScript execution even though the XSS definition has been expanded over the years to several other code execution frameworks well beyond just JavaScript. And, Ive been able to trigger JavaScript execution with this particular attack vector in older Webkit browser engines, but Chromes XSS_Auditor is jumping in to block the XSS due to partial quote escaping by the Uber WAF and Uber is using this to not pay the bounty.

Bug bounties are exactly that: a way of openly researching and then submitting reports on the discovered application and/or infrastructure bug, supported with adequate evidence to prove the report abstract. This isnt, or at least should not be, some digital munitions service where I have to provide a full-on exploit to prove that an application or service is vulnerable to attack, because if I have to go to that effort then why not just legitimately sell the exploit on any one of a number of commercial exploit brokerage auction services?

Well whatever, I am already invested in this so I build another payload, this time evading their WAF and Chromes XSS_Auditor, by injecting an HTML form that says ENTER YOUR UBER USERNAME AND PASSWORD which gets perfectly rendered from https://m.uber.com:

Here is a login form. Not properly formatted, because I am not a web developer or professional phisher.

So now its a completely verified critical security vulnerability, with working POC that will harvest usernames and passwords from an Uber mobile endpoint, and SSL-protected with Ubers signed certificate. The Uber development team gets involved, and additionally verifies that yes, they can execute arbitrary JavaScript code from any *.cloudfront.net host, so these are three distinct critical severity security issues: reflected XSS, HTML content injection, and a CSP that allows execution of arbitrary JavaScript from any *.cloudfront.net host.

So Uber pulls the https://m.uber.com endpoint, and starts redirecting the various offending applications to their OneLogin SSO portal.

Followed by locking and then closing without payment all of my submitted security reports, so that they cant be viewed or publicly disclosed.

And now the HackerOne / Uber Bug Bounty report submission button:

TL;DR:

  1. Uber maintains GPS coordinate tracking data for tens of millions of people in the U.S. and abroad, so the security of their information assets is almost a matter of public interest.
  2. All of the recent bad press about the corporate culture at Uber is really real.
  3. Uber is not serious about their security efforts, and their HackerOne Bug Bounty is completely bogus.
  4. If you invest any time and effort into HackerOne Bug Bounties, HackerOne does not honor their minimum bug bounty guarantee, and will not go to bat for you if you have a dispute with one of their well-placed vendors such as Uber.

Caveat Emptor.

[01/26/2018 Update on HackerOne Mediation]

https://medium.com/bread-and-circuses

Continue reading on medium.com