Exploiting CORS to perform an IDOR Attack leading to PII Information Disclosure

Every Bug Hunter loves PII Information Disclosure, right? So do I, and recently I came across a very similar vulnerability while hunting on a target. The vulnerability was not difficult to exploit once the vulnerable endpoint was discovered, but what made it difficult was to identify the random components in the request. This might have now cleared a little in your mind, how “CORS” helped me in successfully exploiting the vulnerability. Hello Hackers, my name is Harsh, also known as notmarshmllow. Let’s go a little deep into the process.

The application was an E-Commerce Platform and as usual, I was looking for Business Logic Vulnerabilities in the application. First few hours were just understanding application’s workflow, manipulating data, sending request to repeater, looking for other vulnerabilities such as XSS, but the application was pretty secure.

I took a break and went out for some fresh air. On reopening the application, I started testing the CHECKOUT functionality. On checkout, the application was asking for user’s delivery address and credit card details as expected. I observed the URL of the checkout page and it was “https://redcorp.com/20183638/checkout/700dd776teu8890abcdpo12ha0”. If I swap this hash with other user’s hash, the items in my cart on my checkout page would change. This indicated lack of authorization but still, the application was neither swapping accounts nor changing the items in the Cart, except only at the time of checkout, this didn’t had enough impact to report. In simple words, it used to load other user’s cart’s items.

Later, I was going through my Burp Suite’s History and I found a different endpoint “/wallets/checkouts/700dd776teu8890abcdpo12ha0.json” which contained the same hash which is mentioned above. This hash used to store the data of the user’s account. Things started getting interesting now. The endpoint “/wallets/checkouts/” didn’t checked if the user is authorized to access the data or not. On swapping attacker’s hash with victim’s hash, it would load victim’s account’s data in the response. Alright, so now we have something to report. By replacing other user’s hash on “/wallet/checkout/random_hash.json” endpoint, we can steal all details of other users. But, random hashes are difficult to guess and brute-forcing them is waste of time. If somehow, I manage to steal other user’s hash, I can view their name, home address, credit card details and much more. But how ?

I searched for the hash in Burp Suite using the Search Function to check if it is leaking somewhere and I was correct. Third Party Applications, integrated in the target application for transactions and validating Credit Card Numbers were able to access this hash. CORS was allowing them to access data form the request. It was necessary for the application to share data with third party applications to validate it. But, this can help us in accessing the data too. The CORS was configured to allow any domain to fetch data from the request. And hence, we can also fetch these data.

An attacker will first exploit CORS to fetch the random hash of the user and replace the hash to access victim’s data. This included Name, Address, Credit Card Information, Payment information and everything related to a user’s account.

Since, CORS cannot be blocked, the company fixed it by validating and blocking unauthorized access to the endpoint.

Hope you found this helpful.

You can follow me on Twitter @notmarshmllow