Today I’ll be discussing about the IDOR (insecure direct object reference) vulnerability in an application. Where I was able to take over the account via email change confirmation link. I’ll be referring the target company as a pyrus.com.
What is an IDOR?
There can be many variables in the application such as “id”, “pid”, “uid”. Although these values are often seen as HTTP parameters, they can be found in headers and cookies. The attacker can access, edit or delete any of other users’ objects by changing the values. This vulnerability is called IDOR. If there is UUID. There is rare chance to get the IDOR, unless it’s leaking in URL or any other location
Common places to find IDOR
Most of the time people tries to find out IDOR on update profile section and there are many chances that profile section would be secured against IDOR. As this is the prime module to breach the PII data. Now question arises, where do I find IDOR?
Well this entirely depend upon the application structure and functionality. The more functionality will lead you will discover the hidden IDOR which would be even more complex to understand as per developers perspective.
If you are getting 403 on POST /api/user/1234 that is updating the profile. Try to convert request in GET method and see you can see the users details unauthenticated
For POST request body. A parameter name can be anything as per the application. For example you have created an assessment in an education portal. Then it would be assessment_id or it vary on the different component of application.
If you require uuids to finish the IDOR exploitation, look through the same relevant mobile API endpoints for the webapp.
Add .json to the end of the URL to get the data. For instance, api/v1/user/1234.json
Change the api version from v1 to v2.
On my way to hunt IDOR
So, there was feature, where user can sign up to the account without setting up password, setting up the password was later part after logging in. Even if the user wants change the email, a verification link will be sent to registered email. Now here the game was started
Few Pre-requisites before proceeding for this attack
Enumerable ID
Verification Email Link visible in URL
Victim must not setup password, after register
Step to Reproduce
As an attacker, I signup into the application
after setting password, there was an email change functionality
I went to the change email functionality.
So far, we have done everything from the attacker point of view. Now it’s time to proceed with victim’s account
Here, I logged as a victim’s account, I haven’t setup the password yet. As soon as victim’s open the attackers given link (UserID parameter’s value containing the victim’s ID only ) the system will change the victim’s email from backend, but from UI, email will remain same. Now whenever victim tries to setup password. A password setup will be sent to attacker’s new email that is [email protected] shown in above image.
Below URL in image is edited with parameter. we have enumerate the victim’s ID in it.
Takeaway keys
When you are testing an application, make sure to note ID’s on password reset and email verification.
Understand the application’s workflow is goldmine and you will eventually find vulnerability, once you are familiar
Note down if the application is assigning UUID. Try to find if it’s leaking in response error.
Do not limit yourself to understand the application, take your time and eventually you will be able to find IDOR
Last but not least. In rare cases like above it may be possible. An application has a feature to setup password after signup
About Payatu
Payatu is a Research Focused, CERT-In impaneled Cybersecurity Consulting company specializing in security assessments of IoT product ecosystem, Web application & Network with a proven track record of securing applications and infrastructure for customers across 20+ countries.
