Introduction
This time, I was hunting for vulnerabilities in a e-commerce platform, which hosts over 300 stores. After enumerating all the subdomains, I noticed that stores using the free plan had domains formatted like: “storename.ecommerce.com”. I chose one and started capturing traffic with Burp Suite.IDOR (Insecure direct object references)
While browsing the website with Burp Suite active, I noticed that the requests to display the store items were being made to an external server, such as:
Analyzing the response from this request, I noticed a parameter id, which included the store's ID that I was currently viewing.
From there, I decided to search for more IDOR (Insecure direct object references) vulnerabilities. Then I clicked on the login area of the website and found a request being made to the site itself:
This request, as shown above, was exposing the name, WhatsApp number, email, and the store’s ID. With this information, I could already create a report. However, I decided to analyze the site further to see if I could find other vulnerabilities.
While still in the login area, I decided to create an account. After logging in, I observed another request to that external server, which included my account ID and, as a result, retrieved my account information from the server:
Noticing that the number corresponding to the ID was a sequential numeric value, I decided to change my ID in the request, from 197748 to 197747. As a result, I was able to extract the personal data and the password hash of another user using only the ID:
Just like that, I could extract the personal data of 197,747 users. Since the server handling the store’s requests was hosted externally, I was able to access the data of all users who created an account on a store built with this e-commerce platform, even if I wasn’t in the specific stores where they registered. After that, I wrote a report for the company responsible and continued searching for vulnerabilities.
Password Reset Poisoning
After analyzing all possible requests within the store itself, I decided to create an account on the e-commerce platform and set up my own store. By creating an account, I received a domain with my username and the platform’s domain, “nillsx.ecommerce.com”. Within the store creation area, I decided to test the forgot password feature in the login page.By entering my email and clicking on ‘request new password’, the following request was made:
Upon observing the response from this request, I noticed that the token for resetting the password was being exposed. To confirm, I opened my email and compared the URL with the token:
With this, I could change the password of any store using only the owner’s email. I decided to change the password to observe how it was done, and the following request was made:
Analyzing the request, I noticed that the token was not used for identification. Instead, the store’s ID, name, and email were used. Knowing this, I decided to try changing the password of the store where I had found the IDOR vulnerability exposing the email, store’s ID, and the owner’s name.
After using the same request, modifying these details and filling in a password that I controlled, I was able to change the store’s password and log in using the owner’s email and the password that I had just changed.
“Why does this pose a security risk to all the stores on this platform?”
It’s a simple question to answer, knowing that I can change the password of any store just by entering it, capturing the request that exposes the necessary information, and changing the password without any email being sent to the store owner. This results in a silent account takeover that does not require any interaction from the administrator user to occur.
In conclusion, always try to chain your vulnerabilities, as sometimes this can lead to a bigger vulnerability.