IDOR - sudokom/All-About-Red-Team GitHub Wiki

Fuzzing + IDOR = Admin TakeOver

Description

We will call the victim web “example.com”. This objective has 6 well defined user roles. The user with low privileges I call it “Low Privilege” and the one with higher privileges I call it “Super Admin”.

Step 01

I love the fuzz, so first of all I started with fuzzing against the endpoint “/api/FUZZ” without login in the app, using the tool ffuf:

I found 4 endpoints, 2 of them are important here:

user/users
user/updateuser

Step 02

I make a request against the found endpoint and I can see that the server only accepts the POST method:

Step 03

I change the method to POST:

And I can see that a message is displayed for lack of authorization to interact with the resource (endpoint):

Step 04

At this point, I need an authorization token. To obtain it, I log in to the application with my “Low Privilege” user account:

I click on any request and intercept the valid request on the backend, which attaches the “Authorization” header with the JWT:

Step 05 From the endpoint “/api/vehicle/getLoggedInUserBookings” I can see a header “Authorization: Bearer [token]”:

Step 06

I copy and paste this header in my request from Step 03. I add the “Authorization” header with the token that I captured previously and make the request. At this point I noticed a new error message returned by the application:

Step 07

Now, the first thing I think about is “balancing” the request to get a clean response from the server. This got me thinking about changing some headers like “Content Type” and “Accept”. Also, I always add a random parameter (JSON format) in the request with a random value to determine how the server reacts:

Step 08

My first thought when faced with a new API is to save every single parameter I come across along the way. Continuing with this thought, I use the parameters I found in the request from Step 05 to debug the responses and try to get an accurate HTTP 200 OK response:

The message “User details fetch successfully” tells me that everything is fine!

Step 09

It is an important point in the exploitation, since I must look for one or more parameters that allow me to obtain more information.

Okay, using fuzzing techniques again, I find a valid parameter. This parameter was found with the name of ‘“role: 1”’:

The correct syntax to get the correct result with ffuf is as follows:

ffuf -w g0ld3n-api.txt -u https://vulnerable.com/api/endpoint -X POST --data '{"param1":value1,"param2":value2,"FUZZ":6}' -H 'Authorization: Bearer JWT'

Step 10

Then I send the request with this new parameter (role) and the server returns me confidential information about all the users with the “role” equal to “6” corresponding to the Low Privilege role:

Step 11

At this point I can detect that the API is vulnerable to IDOR in its functionality to view user information. Now, will it also be true for the “update user” endpoint found previously in Step 01?

I use the parameters found in Step 10 and start debugging to find a valid response from the server against the endpoint “/user/updateuser”. Once I achieve the “balance” to make the correct request, I change the value of the parameter ‘”role “: 6’ to ‘“role”: 1’:

Role 6 = Low Privilege
Role 1 = Super Admin

I log in again with my user and I see that I am now Super Admin.