4 ms·

Okay, so for the first 4 bug reports, I'm on Uber's side. In their Hackerone program details it says that one of the valid close states of a report is [1]: > d

Okay, so for the first 4 bug reports, I'm on Uber's side. In their Hackerone program details it says that one of the valid close states of a report is [1]: > 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 https://hackerone.com/uber

GregoryVPerry 9y ago
If those were vulnerabilities discovered prior, then surely they could cite to the prior report or an internal ticket to that effect. These weren't previously discovered issues, especially the certificate pinning Surface app one. Their own Bug Bounty Treasure Map specifically states that all requests to that mobile endpoint are certificate pinned, but aren't in the Surface app. 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.
- EnFinlay 9y ago
  > Then they disabled completely the Uber Report Issue button 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.
michaelt 9y ago
it doesn't make sense for Uber to a) publish a list of current unpatched security vulnerabilities Hackerone could require them to publish a list of hashes of unambiguous descriptions of known bugs. That way they could prove beyond doubt which issues were already known - much like astronomers published anagrams to prove their discoveries' priority in the 1500s. It wouldn't solve the problem of people wasting their time rediscovering bugs that don't pay out, of course.
- deleted 9y ago
  [deleted]
- tomxor 9y ago
  I was going to suggest hackerone should be responsible for both storing and arbitrating known bugs but this is even better. 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.
  - zipwitch 9y ago
    This would appear to be consistent with what I've personally observed of Uber's approach to, well, pretty much everything.
- technion 9y ago
  I think it would go a long way just stating when they became duplicates. It would be hard to be mad at Uber if another person reported the same bug two days earlier. 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.
deleted 9y ago
[deleted]
rzimmerman 9y ago
Honestly Uber's response to all of these seems pretty professional and reasonable. The submitter was hard to work with and seemed pretty eager to jump to conclusions about the Uber team's motivations. I haven't seen the details of the JavaScript XSS one but given the past behavior I'd understand some skepticism. Their response to the Microsoft Store lack of cert-pinning seems fair (though disappointing for the submitter): https://hackerone.com/reports/293358 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.

GregoryVPerry 9y ago

If those were vulnerabilities discovered prior, then surely they could cite to the prior report or an internal ticket to that effect. These weren't previously discovered issues, especially the certificate pinning Surface app one. Their own Bug Bounty Treasure Map specifically states that all requests to that mobile endpoint are certificate pinned, but aren't in the Surface app. 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.

EnFinlay 9y ago
> Then they disabled completely the Uber Report Issue button 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.

michaelt 9y ago

it doesn't make sense for Uber to a) publish a list of current unpatched security vulnerabilities Hackerone could require them to publish a list of hashes of unambiguous descriptions of known bugs. That way they could prove beyond doubt which issues were already known - much like astronomers published anagrams to prove their discoveries' priority in the 1500s. It wouldn't solve the problem of people wasting their time rediscovering bugs that don't pay out, of course.

deleted 9y ago
[deleted]
tomxor 9y ago
I was going to suggest hackerone should be responsible for both storing and arbitrating known bugs but this is even better. 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.
- zipwitch 9y ago
  This would appear to be consistent with what I've personally observed of Uber's approach to, well, pretty much everything.
technion 9y ago
I think it would go a long way just stating when they became duplicates. It would be hard to be mad at Uber if another person reported the same bug two days earlier. 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.

deleted 9y ago

[deleted]

rzimmerman 9y ago

Honestly Uber's response to all of these seems pretty professional and reasonable. The submitter was hard to work with and seemed pretty eager to jump to conclusions about the Uber team's motivations. I haven't seen the details of the JavaScript XSS one but given the past behavior I'd understand some skepticism. Their response to the Microsoft Store lack of cert-pinning seems fair (though disappointing for the submitter): https://hackerone.com/reports/293358 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.