Abusing access control on a large online e-commerce site to register as supplier
January 2019 (404 Words, 3 Minutes)
Abusing access control on a large online e-commerce site to register as supplier
Introduction
During my evening bug hunting, I stumbled upon an insecure access control vulnerability in a large e-commerce retailer (claims to have couple of hundred million users) that allowed me to register myself as a supplier without an invitation code.
I’ll walk through discovering the vulnerability, however, keep the company anonymous as they currently do not run a public bug bounty program and I’m disclosing the vulnerability following the openbugbounty rules.
Discovery
I usually start my bug hunting by enumerating the domain name using OWASP Amass (https://github.com/OWASP/Amass) and the Chinese version of Shodan e.g. https://fofa.so/.
OWASP Amass offers a lot in enumerating subdomains as it scrapes data sources, brute forces recursively, crawls web archives and performs DNS sweeping. Some of the most known sources is included e.g. Threatcrowd, VirusTotal, Riddler, CertSpotter, FindSubDomains, Entrust, crt.sh to name a few… A simple command line, shown below, can be very fruitful.
amass -ip -src -d example.com
Enumerating Results
Once I’ve gathered a list of domain names I start by simply browsing each site, focusing on sites that might not have been developed as securely e.g. supplier logins, administrative pages etc.
On the specific target I quickly identified the supplier.domain.com page and fired off with BURP and Firefox.
I then proceed to investigate each functionality e.g. search, registration, contact, password reset, logins etc. Looking at the responses, source code and even injecting polyglot strings. (more on that here: https://github.com/0xsobky/HackVault/wiki/Unleashing-an-Ultimate-XSS-Polyglot)
Whenever a specific function draws attention, I make use of the Burp Function to scan defined insertions points. Simply send the request to the Intruder and enable the scan as shown below.
For this specific vulnerability it wasn’t even required to go this far.
Looking Closer
What really drew my attention was the registration page, and I had to go back to the basics on BURP here. The page allows a supplier to register, however, requires an invitation code.
Looking closer at the requests, especially as I enter a fake invitation code, the keywords were being sent to a supplier code validation API and returns a simple json response with true or false. Example of the API request to validate the invitation code:
Example of the json response received:
Now when using the Repeater function, I could validate how the response looks and play around with the parameters. I then though, hey, what if we changed the response to true, would I bypass validation.
With the Burp proxy enabled and intercept on, I was able to stop at the validation code request being sent. Example from website shown below.
Without modifying the request, we can ask Burp to capture the response as well by using Action, Intercept, Do intercept response. This is sometimes overlooked.
I fired off the request and awaited the response, with the response received back a quick modification to true and validation bypassed.
After the request is forwarded the validation code was validated successfully by the website and allowed me to complete the registration as a supplier.
Reporting
I fired off a mail to the company’s security mailbox in hope of response. However, after a few days I also logged the vulnerability on openbugbounty and awaiting further response.