it doesn't make sense for
Uber to a) publish a list
of current unpatched
security vulnerabilities
It wouldn't solve the problem of people wasting their time rediscovering bugs that don't pay out, of course.
It's really hard to not think Uber is simply playing hackerone to get free penetration testing here by responding to everything as "already discovered" or "out of scope"... A dangerous game though if people catch on and get pissed off enough and just publish it like this, I can't really blame the author, the whole process sounds like bullshit.
It would be easy to be mad at Uber if this had been sitting in an internal bug tracker for three years just getting "closed, duplicate" everytime someone made a Hacker One report.
Their response to the Microsoft Store lack of cert-pinning seems fair (though disappointing for the submitter): https://hackerone.com/reports/293358
> This limitation is already known to us and as such we'll be closing this duplicate per our program guidelines.
to which he replies:
> Cute. Big surprise.
They should link to a submission if one exists, but it's possible and reasonable they already had an internal ticket.
The second issue, not revoking tokens on the server side after logout, the Uber rep replied:
> Thanks for the report, but after looking into it, this is a known limitation of our legacy authentication system and we're actively working on a new system that will replace these long-lived tokens with a more mature bearer token. Currently, the value associated with the x-uber-token HTTP header is a token that is only changed upon password reset.
The submitter added a long list of CWE items for OAuth, one of which was relevant (CWE-613: Insufficient Session Expiration). The Uber rep replied:
> Closing it Informative is not a judgement on the validity of the report -- it simply indicates we already knew about this and are actively addressing it already.
Seems reasonable that Uber's team knows their tokens don't expire and that it's not a good practice.
The rate limiting on the promo code endpoint report is the worst. It looks like Uber actually forwarded this one on to an internal expert, who replied with:
> we would consider the lack of multi-factor authentication a best practices concern, out of scope for our bug bounty program. Additionally, Uber tokens (UUIDs) are made up of 128-bit highly entropic values, making them very difficult to guess or brute force. We’ll be closing this report Informative, as this does not pose a security risk in itself. We wish you the best of luck on your next report!
Which is completely fair (you'd have to try ~10^29 values to get a valid token assuming a billion accounts, which would take millions of years at 1 trillion requests per second). The submitter argued their PRNG might be broken but provided no evidence that was the case. The submitter then posted some very hateful personal attacks against the people responding, including:
> Oh my God. Are you seriously the Program Manager for Uber's Security Division, with a 2013 psych degree and zero relevant industry experience other than technical recruiting? LULZ
I can understand feeling less than obligated to give a payout on these.
Don't open a bug bounty if you have unresolved known issues unless you are prepared to pay out, thats bogus.
All of your other points are "I don't believe him" and "here is some unrelated technical information about uuids that while correct is not really the point". Cool, good for you. Didn't need to put that in a blog post though.
But the best part is, when I was reporting various issues to the Bug Bounty, their staff is actively fixing stuff on the backend (I was getting different application responses after the initial report was filed, but only until I gave them more info on the WAF and XSS_Auditor evasion stuff did they finally pull the whole application offline). And then they still didn't pay anything on the bounty.
Yeah I sent HackerOne a bunch of mediation requests, each response was a different excuse why they won't get involved with it. My "Signal" is too low or it's within Uber's discretion to close out the reports etc. Then they disabled completely the Uber Report Issue button. Yawn.
I don't have enough signal to make a report, but the button doesn't 404 for me, so my guess is you've been shadowbanned.
> then surely they could cite to the prior report or an internal ticket to that effect
Yeah, they should, at least to build the relationship. Public programs have so many erroneous report they probably stopped doing the "nice" thing ages ago.
> But the best part is, when I was reporting various issues to the Bug Bounty, their staff is actively fixing stuff on the backend - that XSS issue they were trying to fix on the backend, but without paying anything for the discovery. I was getting different application responses after the initial report, but only until I gave them more info on the WAF and XSS_Auditor evasion stuff did they finally pull the whole application offline. And then still didn't pay.
If this is true, that's really bad. I'd be curious to hear the other side of the story if there is one.
> duplicate -- a vulnerability that has previously been found either internally or via Hackerone
As much as it sucks to find a bunch of vulnerabilities and not get them paid out, it doesn't make sense for Uber to a) publish a list of current unpatched security vulnerabilities or b) payout everyone who reports the same vulnerability (make n accounts, report the same thing in each one, get minimum payout * n). I'd say it's off base to say that Hackerone didn't have your back. They were duplicates. No payout. Of course, this does mean taking it on faith from Uber that they WERE aware of these vulnerabilities.
For the final report...that's straight bullshit. Did you ask for mediation from HackerOne on that one? Cause if it's an XSS which triggered them to change the code, that deserves a > minimum payout.
[1] https://hackerone.com/uber