Recently a major food delivery company discovered an IDOR vulnerability in their app, which exposed user-sensitive payment information. This flow allowed unauthorized access to read such as Username, first 6 and last 4 digit number of credit cards through the manipulation of payment_method_id.
What do we discuss in this article?
> IDOR
> Zomato IDOR
> Exploitation
> Remediation
> Conclusion
IDOR (Insecure direct object reference)
Insecure direct object reference is a type of access control vulnerability in digital security. This can occur when a web application or application programming interface uses an identifier for direct access to an object in an internal database but does not check for access control or authentication.
This basically means you can access sensitive information by brute forcing ID, number, etc.
IDOR can prevent direct object references, implement user input validation, and implement globally unique identifiers, (known as GUIDs) or random identifiers.
Zomato IDOR
Prateek Srivastava the security researcher has found IDOR in the Zomato app. While browsing through restaurants and dishes, they found something interesting. they just added to the card and went to payment options, they noticed his previously used payment methods presented there.
They started intercepting all the requests going through the phone. As they made payment once again, they found lots of requests sending a lot of parameters to fetch default_payment_options. One of those parameters was payment_method_id which is vulnerable to IDOR vulnerability, they started increasing and decreasing the number such as 1, 2, etc to get results from other users.
When they changed the payment_method_id to a random number, they could see the payment information of some random User. such as Username, first 6 and last 4 digits number of credit cards, and other information.
Exploitation
They started to make an automation script and burp suite intruder to exploit IDOR, they figured out that payment_method_id’s were sequential wasn’t a hard task. Also, There was no rate limit at that place, they started intruding to brute force and changed the last 4 digits of payment_method_id’s and they could fetch details of random people without even getting rate-limited.
The absence of rate limiting was a crucial oversight on Zomato’s part. Rate limiting is a technique used to restrict the number of requests a user can send in a given period, making it harder for attackers to brute-force their way into sensitive information. Without this safeguard, we were able to automate the attack and retrieve payment information from multiple users.
Remediation
Introducing Random Identifiers: Moving away from sequential payment_method_id values to make it harder for attackers to guess valid IDs.
Adding Rate Limiting: To prevent automated brute-force attacks, Zomato implemented rate limiting, ensuring that users cannot send excessive requests in a short period.
Conclusion
In conclusion, the IDOR vulnerability found in Zomato's app, This particular flaw exposed sensitive payment information. This case serves as a reminder that businesses must prioritize access controls, randomize identifiers, and implement rate limiting to prevent vulnerabilities.
