Some errors are occasional, others result from poor design, in this case, finding a vulnerability allows you to find many others…

Hello hunters, I recently found 10 IDOR vulnerabilities in a few hours on a single program, let’s talk about it.

Definition from PortSwigger :

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. The term IDOR was popularized by its appearance in the OWASP 2007 Top Ten. However, it is just one example of many access control implementation mistakes that can lead to access controls being circumvented. IDOR vulnerabilities are most commonly associated with horizontal privilege escalation, but they can also arise in relation to vertical privilege escalation.

In short, exploiting this vulnerability allows us to perform actions or access information/resources to which we are not supposed to have access, whether it is data belonging to a user with the same privilege level as us (horizontal privilege escalation) or a user with a higher privilege level such as an administrator (vertical privilege escalation).

As indicated in the PortSwigger definition, the attack vectors of an IDOR can be multiple : the magic will happen every time the application uses the data provided by the user (the attacker in our case) to access an object without first checking that the author of the request is indeed the owner of the requested data or that he has the appropriate privilege level.

The way applications retrieve the data requested by the user will differ according to their designs but also according to the features concerned, so the list is not exhaustive; Some will retrieve the objects requested by the user from information (ID, GUID, username, value encoded in Base64…) transmitted via a URL (PATH to a specific file for example), parameters transmitted in the URL, a POST request, or cookies.

Preparing the ground

When I want to test an application for IDOR attacks, I start by creating two accounts, an attacker and a victim. That way, I can try to perform actions and/or access the private information of my victim account through my attacker account without harming the users of the platform.

Once this is done, I log in to the victim account and play with some private features (such as uploading personal information) by passing my requests through my proxy. The first goal here is to analyze the HTTP requests and see if a parameter corresponds to an ID (whatever its nature) belonging to the victim account.

As explained above, an account can have several types of data allowing it to be “recognized” by the server when the request is received and these types of data will differ depending on the feature used : take a notebook and note all these values, they will be essential for the next tests.

Now it’s time to tryhard

After taking note of these values, we can log in to the attacker account and test all the private features by systematically changing the ID (or the concerned value) to those previously noted belonging to the victim account. Being consistent in testing is a plus, divide the application into blocks and move forward as you go to cover its entire surface without getting lost.

It is essential to have a good understanding of the application being tested to know what the expected behaviors when sending a request, and what are, on the contrary, the behaviors that should attract our attention or — at least — arouse our curiosity. An application is not tested in one hour, the more time you spend on it, the more precise your understanding of the architecture and technologies used will be.

You have to put yourself in the developer’s shoes and focus on the less intuitive areas to secure or on the latest features implemented, don’t hesitate to follow the company on its social networks to stay informed of the news.

I like to look for endpoints by testing features from other devices or on web.archive, you can come across old, less secure but still active endpoints!

As this was a private program, I will not reveal the name of the company and will voluntarily change some information. It was a company that allowed to upload of multimedia files (photos, videos…) on its platform.

When testing a feature allowing to saving media, I came across a graphQL request looking like this :

{ 
  "action":"getSaves", 
  "variables":{ 
    "input":{ 
      "infoD":"eyJ0eXBlIjoidXNlcklEIiwiaWQiOiIxODI5MDUifQ==" 
     } 
  }, 
  "query":" (…) " 
}

Some characteristics of the value of the “infoD” parameter easily allow us to guess that it is an encoding in base64, when I decode the value I get:

{"type":"userID","id":"182905"}

What happens if I change the value of the “id” parameter to the id of my victim account, re-encode it all in base64, and then modify the value of the “infoD” parameter of my request?

{"type":"userID","id":"182545"}

eyJ0eXBlIjoidXNlcklEIiwiaWQiOiIxODI1NDUifSA=

{ 
  "action":"getSaves", 
  "variables":{ 
    "input":{ 
      "infoD":"eyJ0eXBlIjoidXNlcklEIiwiaWQiOiIxODI1NDUifSA=" 
     } 
  }, 
  "query":" (…) " 
}

It works! I can retrieve all the media saved by my victim account. Obviously, these are normally private data, no one is supposed to know what you save/favorite.

It is essential to make a slight clarification: for the attack scenario to be valid, it is necessary to be able to obtain the ID (whatever its form) of the victim from the attacker’s account in the event of an attack on a specific person. If this is not feasible, we will have to choose a more generalized attack but the IDs must be easily guessable, for example: 13445, 13446, 13447.. then a simple script will make it possible to acquire a large amount of data.

So we have our first IDOR vulnerability, once a vulnerability is found, you know that it is very likely that you will find others of the same kind and this is particularly true when it comes to vulnerabilities related to access controls. Either the development team has not put in place a robust centralized system in which case you may have a lot of surprises, or it was a poorly implemented feature and/or not connected to the central access control system.

In any case, if you find a particular deficiency in a system, explore this flaw as much as possible, this is what allowed me to find ten similar vulnerabilities on the same platform. Some are simpler, others a little more complicated but all exploit vulnerabilities in access control.

I got a bounty for 3 of the 10 vulnerabilities found, the other 7 were unfortunately duplicates. That’s the game!

Thank you for reading me, if you have any questions do not hesitate to let me know. Happy hunting 🏹

My Twitter account : https://twitter.com/blank_cold