These are low severity reports. The first two require difficult prerequisites for an attacker to exploit, and the last one was not proven to be a security flaw.
#293358: it's not ideal that the certificate isn't pinned, but to exploit this an attacker needs to either install their own root certificate on the victim's device, somehow obtain a private key for a certificate already installed, or have a certificate authority misissue a certificate to them for an Uber domain used by the app.
#293363: an attacker still needs to acquire the victim's X-Uber-Token somehow for this to be useful. It's also somewhat mitigated by the token being invalidated when the victim changes their password.
#293359: as pointed out by Uber, no weaknesses in the token generation algorithm were actually demonstrated, and brute forcing the 2^128 keyspace is infeasible.
Also, the rudeness he displayed was petty and unhelpful:
> given the fact that at least one of your system architects were apparently high when they designed and implemented your bearer token assignment process
> Not completely unexpected though, given the caliber of talent utilized by Uber such as the “security” group that you hail from. You would do well in government security consulting, for sure.
> 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
All in all, rather a poor result for this vulnerability researcher.
