One Bug at a Time: In depth analysis of 3 IDOR bugs

Hello everyone! Thank you for taking the time to read this blog. I will be going in depth on some bugs I have found recently. I will have to blur out a lot of information for company protection purposes but you will be able to grasp the methods from what I show.

Bug Number One:
IDOR leading to disclosure of location of any team

I was hunting on a program on hackerone and I was spidering through their application. For this, I click on every function through the app. I click every single button, and try every single feature it has to offer. Sometimes I will go to the extent of buying the premium version just to get access to more functionality.

I came across this one endpoint: /forecasts/ which allowed you to get the forecast of your teams weather so you know when to have practice or meet. I then looked at the full request in my burp history and saw the full endpoint: “api.redacted.com/forecasts/search?team_id=123” I looked at what type of data I am getting back from the program and the response was showing [State, City, County, Longitude , Latitude ] of the team! Next thing in mind was for me to change the team id. I changed the ID and BOOM! I got a new location with all of this information. An attacker could enumerate a team by its name and exact location.

Proof Of Concept

Bug Number Two: IDOR leading to viewing messages of any user

Stumbling Upon the POST Request
While sifting through the Burp Suite’s HTTP history, I noticed an intriguing POST request — /Messages/MostRecent. My curiosity piqued as I realized this could be a significant entry point into the companies messaging system.

Analyzing the Payload:

Delving deeper into the POST request, I examined the request payload and identified a critical parameter called “userId.” It seemed that this parameter dictated whose recent messages were fetched by the application.

Testing with My Own User ID

I decided to start with my own user ID and crafted a POST request with the payload containing my ID. To my confirmation, the calculator responded by displaying my most recent messages.

POST /Messages/MostRecent HTTP/2
Host: www.redacted.com
Content-Length: 94

{"userId":57231173,"count":18,"freeStepsTrialTest":{"cvid":null,"type":0}}

The Vulnerability Unveiled

With growing concern, I realized that if I could access my messages this way, there was a possibility that other users’ private conversations could be exposed too. The vulnerability of an Insecure Direct Object Reference (IDOR) loomed before me.

Tampering with the “userId” Parameter

To validate my suspicions, I devised a plan to tamper with the “userId” parameter in the POST request’s payload. Changing the value to a random user ID, I executed the request again. To my dismay, the application obediently returned private messages that did not belong to me.

Bug Number Three: Information Disclosure with IDOR

This IDOR was the quickest IDOR I have ever found. I was hunting on a private programming with one of my friends and we were exploring the application. I once again was checking all of the requests through my burp history and found the endpoint:

/v2/groups/ID-HERE

I noticed the ID as usual and change the ID to see what would happen. This bug lead to me being able to get the following information for random teams:

The data returned includes the full names, phone numbers, and amount of users subscribed to the group, among other sensitive information.

1. Deep Dive into HTTP History: When hunting for Insecure Direct Object References (IDORs), always take the time to thoroughly inspect the HTTP history within Burp Suite or any other interception proxy. Frequently, you’ll stumble upon undiscovered endpoints with sensitive functionalities or data that can lead to significant vulnerabilities.
2. Parameter Manipulation Testing: Don’t limit yourself to testing only the most obvious parameters for IDOR vulnerabilities. Go beyond the standard parameters and explore different combinations, custom headers, cookies, or even URL variations. Sometimes, a simple tweak in these elements can expose critical IDOR flaws.
3. Contextual Assessment for Impact: Understand the potential impact of an IDOR beyond the immediate vulnerable endpoint. Consider how the information obtained can be leveraged to attack other parts of the application or the system. For instance, if you can access user data, can you escalate privileges or compromise other accounts?
4. Bypassing Access Controls: Investigate whether there are any access controls in place for sensitive resources. Often, IDOR vulnerabilities can be mitigated by proper access control mechanisms. Attempt to bypass these controls to ensure they are robust and effectively protect against unauthorized access.
5. Comparative Analysis: When you discover an IDOR in one part of the application, check if there are similar functionalities or endpoints that handle similar data. These might be susceptible to the same vulnerability. Look for patterns and commonalities in how the application handles object references.
6. Parameter Whitelisting: Some applications use parameter whitelisting to restrict user access to specific resources. Look for patterns in the allowed values for parameters and test whether you can manipulate these values to access unauthorized resources.
7. Enumerate and Exploit User Roles: If the application employs role-based access control, systematically test each user role to identify potential IDORs. Different roles might have varying access privileges, so enumerate all possible roles and test them individually.
8. Horizontal and Vertical IDORs: Distinguish between horizontal and vertical IDORs. Horizontal IDORs involve accessing the same type of resources belonging to other users (e.g., accessing another user’s profile). Vertical IDORs entail escalating privileges to access higher-level resources (e.g., administrative accounts). Both types can coexist, so check for both.
9. Context-Specific Testing: Tailor your testing approach based on the application’s specific functionalities and requirements. Different applications handle data and resources differently, so adapt your testing methods accordingly to improve the chances of discovering IDOR vulnerabilities.
10. Limiting Scope: While IDOR testing should be thorough, it’s essential to stay within the scope defined by the program or the project. Avoid testing resources that are clearly out of scope, as it may violate the rules and negatively impact your reputation as a security researcher.
11. Document and Report Clearly: When you find an IDOR, document the steps to reproduce the vulnerability thoroughly. Provide a clear and concise report to the development team or the organization, including the potential impact and possible remediation steps. A well-documented report increases the likelihood of a swift and effective fix.