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.
I submit the report to Uber:
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:
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.
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 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: