Tackling IDOR on UUID based objects

Tackling IDOR on UUID based objects

Hi there! I hope all of you are doing well. I am back with my new writeup. In this writeup, i will be discussing about an interesting IDOR which i recently discovered on a private program which had unguessable IDs.

What is IDOR?

Insecure direct object references (IDOR) are a type of access control vulnerability that arises when an application uses user-supplied input to access objects directly.

Traditional Insecure Direct Object Reference (IDOR) typically involves manipulating numerical IDs through incremental changes. However, what I’ve discovered is a unique approach where they had unpredictable IDs. I will detail my approach to uncovering and disclosing the personally identifiable information (PII) of users on the website in this write-up.

Finding the IDOR:

They had primary key with parameter id which they called lead. After poking around, i found an endpoint where we could update our phone number which sent HTTP PUT request to /api/lead/<id>/phone-number .I do use FoxyProxy when it comes to testing for multiple accounts as it offers containered tabs for enhanced isolation and organization. I noticed that the application was not properly validating the ID with their sessions, allowing the manipulation of other user’s IDs, consequently enabling unauthorized changes to their phone numbers. However, it’s important to note that the IDs were not numeric hence not easily guessable. The main challenge was finding a method to obtain these non-predictable IDs.

Tackling the Unguessable IDs:

Here’s a good blog by rez0 to increase the impact of unguessable IDs, but despite my attempts, I couldn’t achieve any positive results on getting valid IDs of other users. After a while, poking around the regestration endpoint, I noticed that the POST request is sent to /api/leads . Experimenting with various attack methods, I managed to discover an unusual behaviour in this endpoint that unlocked the door to the unexpected revel of these unguessable IDs.

While registering, when we try to put the existing user’s email address, it leaked their ID with the error code lead_already_verified

Here we got our peice of information which assembles the whole puzzle.

So this is going to be our Attack Process to dump the PII and update phone number of any user on the site:

Step 1: Get the user’s email you want to update the contact number of and then send a POST request to /api/leads which would return his/her unguessable Lead id .

Step 2: With above lead id send request PUT to /api/lead/<id>/phone-number with desired phone number on the body.

That’s how I was able to update other user’s phone number and even leak their personal informations with 1st request combined with 2nd request.

Take Aways:

Never Give up too early, Take notes of each and every interesting behaviour you find on the target which might be useful for chaining on later findings.

There are countless ways to make something work. If one way doesn’t work, you might find another way that is much more simpler, just need to invest more time on it.

That’s all for this writeup, hope you found it useful. I can’t wait to see you in next one. You can connect with me on Twitter if you wish to. Until then, take care and stay well! 🤞❤️