Random Object Referencing IDs Still Aren't Safe in APIs 💥

This post discusses the common bad practices while using uuids and guids which could lead to vulnerabilities in software/web applications.

Using UUIDs/GUIDs to avoid BOLA

There are several applications that uses uuids/guids instead of id to avoid BOLA vulnerability in their APIs.

But If we use uuids/guids instead of ids does that fix the vulnerability in the APIs?

HELL NO!!!

In this post, I'm going to discuss how we assume that using uuids/guids fixes vulns in our APIs since uuids/guids are bit difficult to be brute-forced (Not Impossible!).

Also, I usually come across several applications which are using mongo object ids directly in their APIs assuming it'll be safe to use object ids directly without any permission checks 💣.

Now, let's discuss a scenario which could lead to data breach/leak even if we're using UUIDs/GUIDs!!

Just Another Hacking Story

Few months back I came across a product's application which helps digital content creators to monetize their work (usually courses) on their platform, engage with consumers, create webpages, etc.

This product will help you to setup your brand digitally. This platform is being used by several influencers to create their brand products/courses.

Its single page web application uses APIs to interact with data and update views for the user. Their Backend Tech Stack uses mongodb database which used mongo object ids directly in APIs. API consisted several endpoints for providing users several functionalities such as:

• SignUp

• Login

• View/Update their details (including payment details)

• Manage Courses (for course owners) - manage course content, price rates, etc.

• Initiate payment for buying course, etc.

As usual I wanted to find loopholes in their product design 😎

⚠️Spoiler Alert: I did find several issues in their web application, APIs and cloud infra; But in this post I'll be focusing on the root cause which led to exploitation of other vulns.

Popping Alert Boxes

Hey!! Vuln API Let Me In!

I started my proxy, navigated through the web app and captured API endpoints.

Me While Pentesting My Targets

After successful navigation, I went through my proxy history and noted endpoints that could be vulnerable.

• SignUp and Login Endpoints (For bruteforcing ATO approach: It had enforced rate limiting per user email/phone)

• Update Details Endpoint (for getting admin perms: which I successfully exploited and got admin perms)

• Few others AND...

• Getting user activity endpoint which dumped complete user document/model including financial data 😄

  • /v4/new-activity-api?requiredUser={mongodb_user_object_id}

Let's only focus on user activity endpoint for now 😉

This endpoint could be data mine for attackers for exfiltrating user data, since it returned several information including:

• Bank details (International and Domestic)

• Phone number

• Email

• Subscriptions

• PAN and Aadhaar card (Indian Identification Numbers, analogy: sorta similar to SSN)

• Uploaded File Links (directly accessible via assets, Maybe I'll discuss this issue how companies are serving PII data from assets cdn assuming object paths will be safe if they're randomly generated and how can we secure it)

• Earnings, Courses and other information for Content Creators.

So How Can Someone Come Across User's Mongo Object IDs?

I didn't had to search for user ids, the API provided it to me 😄.

The creator's profile URL had user's object id in it.

Example:

https://example.com/profile/{user_object_id}/

So I used google dork to extract users profile urls and I had their object ids as well.

site: example.com inurl:"/profile/"

After retrieving id use vulnerable endpoint to get complete user details 🥂

Creator's PII Data leakage 1

Creator's PII data leakage 2

Another way to get hold of their object id was from listing pages or search 😉

Now, I had all registered influencers/content creators and their consumers details with me 😎

User's data isn't safe even if you're using random ids without authorization checks. We should focus on enforcing permission checks instead of randomizing ids.

Conclusion

Random ids won't help us to secure our user's data if we're referencing it somewhere. There will always be a risk of exposing random ids somewhere using which malicious users will be able to exploit our apps😢.

It doesn't matter whether we use integer based ids/UUIDs/GUIDs/Mongo Object IDs, or anything else. It's crucial to enforce authorization checks whether user has permission to access the object id that user is trying to access in order to avoid data leaks/breaches.

???

If you still think using random ids without authorization checks are safe ⚠️

May GAWD SAVE YOUR API 💣💥!!