Finding IDORs, the conceptual way

This is my take on IDORs and how to understand them when you are just starting in the Web Application Penetration Testing.

Process to analyse or understand any vulnerability:

1. What it is?

2. Why it exists (basic and specific reasons)?

3. Impacts (the damage it can cause)

4. Mitigation (ways to prevent it)

Description:

An Insecure Object Direct Reference (IDOR) vulnerability occurs when an attacker can access or modify a reference to an object, such as a file, database record, account, etc. that should be(must be according to me) inaccessible to them. In other words, it usually occurs when the website or webapplication references the user’s IDs or any other object with an integer value in the request method (either GET or POST). If we talk about the OWASP Top 10 then IDORs lies under the category of Broken Access Control. It can be said that IDOR bugs can be used to demonstrate Broken Access Control.

For example, when viewing your account on a website with private profiles, you might visit www.site.com/user=123. However, if you tried www.site.com/user=124 and were granted access, that site would be considered vulnerable to an IDOR bug.

Identifying the IDORs can be a little bit tricky sometimes because the web site/application has an unintended behavior that doesn’t necessarily mean it’s going to favor penetration tester or a bug bounty hunter. In fact, in some cases it’s just an executional bug instead of a security one.

Conceptual Scenario 1:

However, apart from the most basic techniques of finding IDORs as discussed in the above example by manipulating the integer value we can also test for this bug by automation process using BurpSuite. All we need to do is to send the request to the intruder and set a payload on the ID parameter with an incremental numbers list by 1 from start to stop values.

Conceptual Scenario 2:

Furthermore, content length also plays a crucial role in finding IDORs. It can be checked by observing that the content length header in the request can be responsible for distinguished responses. Particularly, it can be said that if a site isn’t vulnerable then we should consistently get some type of access denied message with the same content length.

Conceptual Scenario 3:

Nevertheless, things can always get more difficult than they were. So, in some cases the site tries to obscure references to their object references, using things like randomized identifiers, such universal unique identifiers

(UUIDs) means that they completely wash out the idea of manipulating the integer value. In certain circumstances they achieve it by an alpha numeric string which is in fact impossible to guess. Now, testing for IDORs in this particular scenario will depend on which object you are trying to test it on. For example, if you are attempting to get entry to person profiles with a UUID, create your profile with User A after which with User B, attempt to get entry to that profile in view that you understand the UUID. On the other hand, If you’re trying out particular data, like bill IDs, trips, etc. all diagnosed via way of means of UUIDs, just like the instance above, attempt to create the ones data as User A after which get entry to them as User B in view that you understand the legitimate UUIDs among profiles. Let’s say you are able to get entry to the objects, the problem will still persist as the UUID is unguessable due to the randomization. All is not lost though, At this point, the following step is to try and find an area in which that UUID is leaked. For example, on a team based totally absolutely site, are you capable of invite User B to your team, and if so, does the server respond with their UUID even in advance than they have accepted. That’s one of the ways UUIDs are leaked on the web site/application.

NOTE: IDORs are also responsible for privilege escalation.

What is Privilege Escalation?

In penetration testing, priv. esc. Can be understood by understanding the concept of permissions. For example, suppose there are two friends on the same level in a company A and B but in different departments i.e.; let’s call it Dept1 and Dept2 respectively. Now, according to the company’s security policy Dept1 employees must not be allowed to view into the documents of the Dept2 employees in any way but still employee A can see the complete documents of B and sometimes can even edit the documents as well. This is a classic case of Horizontal Privilege Escalation because both A and B are on the same level in the organization. However, to connect it with the real world you can think of a scenario where one user on a website can see the sensitive data of another user with the same Privileges.

Examples:

Let’s take a quick example of a bug that was found and publicly reported on HackerOne back in 2015 but still relevant under certain circumstances.

Difficulty: Low

URL: binary.com

Description:

In this situation the particular vulnerability can be observed quiet easily as it could be exploited by simply editing the page’s HTML. The key to find this one was to notice the <iframe> tag of the page’s source that included a PIN parameter. That parameter was actually the account ID of the user.

<iframe src=”https://cashier.binary.com/login.asp?Sportsbook=Binary (CR) SA USD&amp;PIN= CR342435&amp;Lang=en&amp;Password=0e552ae717a1d08cb147f132a31676559e3273ef&amp;Secret=1328d47abeda2b672b6424093c4dbc76&amp;Action=DEPOSIT” frameborder=”0" width=”100%” height=”2000" id=”cashiercont” scrolling=”auto” style=”padding:0px;margin:0px;”></iframe>

However, the exploitation began when the PIN parameter was edited and the attacker only needs to know the user ID of the victim. Nonetheless, a secure web site/application should never allow to perform any actions on the new account without validation of the ID parameter but in this case it did. In other words, if you change the ID parameter and the ACTION parameter at the same time then the action would have been performed by the account of the user whose ID you just entered.

The action could be anything ranging from viewing sensitive information of the user to withdrawing money.

Conclusive facts for this IDOR’s observation:

If you are searching out authentication-primarily based totally vulnerabilities, be looking out for in which credentials are being surpassed to a site. While this vulnerability become caught via way of means of searching on the web page supply code, you furthermore might should have observed the information being surpassed whilst the use of a Proxy interceptor.

If you do discover a few sort of credentials being surpassed, take notice after they do not appearance encrypted and attempt to play with them. In this case, the pin become simply CRXXXXXX at the same time as the password become 0e552ae717a1d08cb134f132 in reality the PIN become not encrypted at the same time as the password become. Unencrypted values constitute a pleasing region to begin gambling with.

Mitigation:

IDORs are somewhat complicated to exploit and also to mitigate. However, they couldn’t be mitigated by simply putting up WAFs. In my opinion, I would like to introduce 4 approaches to get rid of them:

1. Website’s Access Control Mechanism must work efficiently and logically, meaning that the permissions on the users must be implemented properly in accordance to their privilege.

2. Generate random user ID tokens like JSON to put up with the more complex UUID and always keep a close eye on the sensitivity of the information as well because IDORs can change based on them and due to these random tokens, even if the web site/application is vulnerable to IDORs, it won’t be exploitable.

3. Instead of using integers for the reference of objects try to use hashed values with proper salting and place them in a hash map like key-value pair. This way, the key-value map can be tied to the session and stored in the Session. In other words, even if the attacker somehow comes up with a way to guess or spoof the generated value, it’s not going to show on the map. It will lead to no exploitation.

References — Web Hacking 101 by Peter Yaworski