IDOR Leads To Account Takeover

IDOR, one of the most common vulnerabilities in applications, can lead to major security leaks. Today, I’ll walk you through how I discovered an IDOR flaw that allowed access to other users’ accounts in the vulnerable application.

Insecure Direct Object Reference (IDOR) is a security vulnerability that arises when the application exposes its internal implementation objects directly to users without proper access controls in place.

Typically, web applications or APIs use references or identifiers to access and retrieve data from their underlying storage systems. These references, if not properly protected, can be manipulated by attackers to gain unauthorized access to sensitive resources.

The vulnerability occurs when the application fails to enforce proper authorization checks before serving requested resources to users. Attackers can exploit this by manipulating parameters or identifiers in requests, thereby accessing data or functionalities they shouldn’t have access to.

For example, an attacker might change a parameter in a URL to access another user’s private files or modify data belonging to someone else. This can lead to unauthorized data disclosure, data manipulation, or even account takeover if the attacker gains access to privileged functionalities.

Finding IDOR Which Disclosed Sensitive Data

While examining the target banking web application and monitoring traffic in Burp Suite, I noticed an intriguing parameter, [userId], within the body of a POST API request (/api/withdraw). Upon further investigation, I observed that the response contained hashed passwords, user emails, and other sensitive user data.

Please note that I have modified certain data in the request and responses below for obvious reasons.

I modified the userID parameter to match the user ID of another user I possessed, which was 4597. As a result, the response included the password of that specific user. While I could have reported this vulnerability as is, I saw an opportunity to escalate its severity.

Account Takeover

I remembered that returning passwords in response, whether hashed or plaintext, is considered poor practice. Moreover, considering that we are also receiving the email ID associated with a userID, theoretically, we could crack the password and gain access to a victim user’s account, but first I need to determine the type of hashing algorithm being used in this scenario.

According to the hash analyzer, the bcrypt algorithm is being used. I used hashcat to attempt to crack the password hash.

After successfully cracking the hash, I submitted the vulnerability as an account takeover, and it was mitigated in just a few days.