A few months ago Uber came out with a new service which allowed businesses to request Uber rides for their customers. UberCENTRAL allowed businesses - large or small - to request, manage and pay for multiple Uber rides on behalf of their customers. The only way to have access to UberCENTRAL is to be approved and luckily I was approved to view the backend.
By using the feature on UberCENTRAL that was provided it allowed the administrator of the company to add operators to their locations. Operators are employees who will request rides on behalf of the companies customers and these operators can be added via their email address, therefore basically any valid email address that was registered with Uber can be added.
Taken straight from Uber’s HackerOne Profile the reason why Uber rewards for enumerating userUUID is due to insecure direct object reference (IDOR). When an attacker is able to perform bulk enumeration of userUUID through an endpoint they can then at that point perform bulk IDOR attacks against their users.
0x01 : enumerate userUUID via emails
With central.uber.com the admin can add operators to certain locations. With that request the usersUUID is available when their email is used.
The attacker can change the operatorEmail and start enumerating through hundreds of thousands of possible valid email addresses.
As you can see the userUUID is visible. The UUID for email@example.com is 906d29c8-7b17-4e90-900e-1af72e1c72a6 which is also shown in the response.
If the email is not associated with an account then an error will show up in the response.
Uber has fixed the issue by removing the userUUID from the response.
September 4th - Reported
September 6th - Acknowledged
September 26th - Triaged
October 6th - Resolved
October 17th - Bounty Rewarded
0x02 : enumerate userUUID via GET request
This is the same exact endpoint as 0x01 but instead of using the POST request, the GET request is used.
With this you will still have to use the POST request in 0x01 to gather emails and adding them to your operator list.
Once again the attacker can change the operatorEmail and start enumerating through hundreds of thousands of possible valid email addresses. At that point once the attacker has enough valid emails they will be able to change the HTTP method from POST to GET.
By changing the HTTP method from POST to GET will allow you to get all the operators you have added to your company. This will show all the operators userUUID.
Uber has fixed this issue by removing the userUUID associated with the email but every time you do the GET request, the userUUID will show up with a random userUUID. Sneaky sneaky!
October 18th - Reported
October 19th - Acknowledged
October 19th - Triaged
October 24th - Resolved
October 31st - Bounty Rewarded
0x03 : Exposure of full name, phone numbers, emails and userUUID
After finding the previous endpoint, that made me test out other endpoints with the GET HTTP method. When an operator is added to a location their information will show up ONLY IF they log into UberCENTRAL. If the user does not log into UberCENTRAL with the account that was added, no information will be revealed.
Once the operators are added to the location, they need to be selected to be associated with that location. Once you do that you can do the following request.
The original HTTP method was PUT but if you change it to GET you will reveal more information.
All the operators need to be selected to gain their information. The operatorUuid is not the users userUUID.
The following response shows up with the users full name, phone number, email address (which we enumerated through to get all this information) and the userUUID.
Uber fixed this issue by placing NULL in the firstName, lastName and phoneNumber fields. As for the userUUID, everytime you do the GET request it will respond back with a random userUUID. Once again sneaky sneaky!