IDOR Leads To Leak Any Uber Eats Restaurant Analytics

Hi fellow Hackers,
At first Ramadan Kareem! Wishing everyone a very happy Ramadan. Today I will write about an Insecure direct object references (IDOR) vulnerability that I recently discovered in Uber Eats Restaurant.

The Uber Eats Restaurant web application at https://restaurant.uber.com/ is using GraphQL. Back in March, I was doing a collaboration on a Uber report with Sifat Bhai. On that engagement, he discovered an IDOR in GraphQL that leaks data of other Restaurants but that leaked data was not giving any sensitive information to make a report on it. So I decided to take a look at that functionality.

Issue Background: In the Uber Eats for Restaurant dashboard, there is an Analytics option where store owners can see Restaurant Analytics of the last 12 months. Analytics endpoint looks https://restaurant.uber.com/v2/home/{locationUUIDs}/analytics/sales where multiple GraphQL requests pullup all data and parse it in that webpage to a readable view. Now I noticed all those requests contain locationUUIDs parameter like "locationUUIDs":["0292a209-df33-496b-b65b-192c86603d48"]} where 0292a209-df33-496b-b65b-192c86603d48 is my own test account locationUUIDs value. When I changed the locationUUIDs value to another account locationUUIDs value it responded the same with some JSON data in the body that took my attention. But still response body data is not helpful as it is not properly readable and in order to read the data we need to parse it through the webpage.

Automation with Burp: To do the data parsing job I used Burp Suite Tool’s Match and Replace option.

  1. In Burp go to Proxy => Options => Match and Replace
  2. Click on Add and set up a rule like the below screenshot where Match value is my own restaurant’s locationUUIDs and Replace value is any other restaurant’s locationUUIDs.

    Match-and-Replace

  3. I also added a rule like the below screenshot to change the currency from BDT to USD to get all analytics in USD currency.Currency Match and Replace

Final Exploit

  1. Visit https://restaurant.uber.com and log in using a valid restaurant account username and password and do proper authentication.
  2. Now setup Burp Suite Tools with that browser and keep Intercept OFF
  3. Visit https://restaurant.uber.com/v2/home/{victims_locationUUIDs}/analytics/sales
  4. All request of the browser will go through Burp & Match and Replace rule will replace all locationUUIDs parameter value and all data will parse into a readable view on that webpage.Sales dataSales by Item

Impact

An attacker can access all analytics of a restaurant what includes actions

  • Choose a date range to see that date range analytics.
  • Orders analytics view and Clicking on Download will Download a CSV copy.
  • Track orders placed over time to monitor a restaurant’s popularity.
  • Track ticket size over time to see if a restaurant’s receiving larger orders.
  • Learn when a target store tends to generate most of its sales.
  • Learn when customers tend to place the most orders in a target restaurant.
  • Learn when customers tend to place the largest orders in a target restaurant.
  • See which items are a restaurant’s top sellers.

To exploit a stored attacker just needs the locationUUIDs parameter value and I showed the Uber Security team a promising way to fuzz the value for any restaurant. This vulnerability was reported in report #1116387 under Uber Bug Bounty Program and $2,000 Bounty was Rewarded. Check out the video POC too.

Hope you guys enjoyed this one. 

#Stay_Home
#Stay_Safe
#Wash_Your_Hand_Frequently
#Hack_The_Planet🔥

20 Responses

  1. this blog isn’t useful at all , the only thing that could be useful is if you explain how you were able to guess the uuid of any restaurant and you don’t explain that

    1. I was able to get any store uid too, but can’t disclose that part as in my article review process uber team asked me to remove that part for their internal reasons 😇 and I can’t disclose that part without their permission.

      1. I don’t think “fuzz” is the correct word as the space for burteforcing the all possibilities of UUIDv4 is too large to be feasible. I think it was more likely that you found the stores’ UUID through other pages.

        1. You are correct on this. I was able to get any store uid, but can’t disclose that part as in my article review process uber team asked me to remove that part for their internal reasons 😇 and I can’t disclose that part without their permission.

  2. Thank you for awesome write up. Actually If I found this bug, I think that “I can’t find uuid of anyone” Because this uuid’s are not fuzzable. The complexity becomes too high.

    Are you found a way to find, or really they accepted the vulnerabilty on this status I really wonder.

  3. wonderful post, very informative. I wonder why the other specialists of this sector do not notice this. You should continue your writing. I am confident, you’ve a great readers’ base already!

Leave a Reply

Your email address will not be published. Required fields are marked *

RECENT TWEETS

RECENT POSTS