Hacking India’s Biggest Fintech Provider With a Simple IDOR

What are IDORs?

IDORs (Indirect Object References) are one of the most common vulnerabilities in any application but they are extremely dangerous and have the most impact on any business. IDORs are simply vulnerabilities that allow user X to access user Y’s data and perform activities on their behalf without properly validating themselves to be user Y.

Vulnerability Summary

Impact: User Financial + Personal Data Leakage
Target: Undisclosed
Bounty: Undisclosed
Date Reported: 05/12/2022
Severity: Critical

The Findings

This particular target provides instant credit to users under the Buy Now Pay Later banner which essentially means they provide you with a fixed credit limit every month that is directly linked to your phone number and can directly be used to pay inside various apps and stores without the need of any card based on your credit score they pull out of your financial data.

A user could make multiple transactions every month. At the end of the month they are presented with a statement for the month which includes: Their name, E-mail, Phone Number, Due Date, Previous Due Amount, and a list of all the transactions for that month for that month with vendor names, transaction IDs and the corresponding amounts spent on the same, this information is displayed freely on both their mobile and web application.

They had an interesting feature here to generate PDFs for these statements just like any other bank where each statement was linked to a specific statementId and this would generate a PDF of transactions on the fly. This means this PDF is never stored on their servers but instead always dynamically generated whenever the user requests it.

The API endpoint for this request looked like:

POST https://api.redacted.com/api/redacted/statements/downloadStatementPdf/{statementId}

Here {statementId} is mapped to different user’s statement IDs and is a simple all-numeric 10-digit guessable number. To my surprise, if I incremented or decremented this value by 1, it would then return another user’s statement for the month! There was no check in place in this endpoint to ensure that the current authenticated user = the statement’s owner user.

I now had access to millions of users’ financial info and transactions and even their personal sensitive information linked to their Transaction Vaults. This meant that their entire user base’s data was compromised! It was then immediately reported to and fixed by the target company under their Bug Bounty program.

Conclusion Notes

IDORs can be easily prevented by using some of these mechanisms:

1. Unguessable UUIDs: Make use of UUIDs that are unguessable, especially in places where there is guaranteed sensitive data present. This makes it nearly impossible for an attacker to guess another user’s UUID even if the application is vulnerable to an IDOR.
2. Unified Authentication: Make use of authentication that is pluggable and not optional. Verify IDs to map back to token users rather than sending the request straight to the actual controller that handles these requests.