IDOR vulnerability on invoice and weak password reset leads to account take over
This year I started doing bug bounties and I only got valid p5 report and my report for p4 and p3 got rejected.
This January 23 I was asked by someone I know to test their website for vulnerabilities and I agreed to it since this would give me a good amount of experience. While testing in a span of 5 to 6 hours I managed to find 5 vulnerabilities. I asked if i could disclose this and he agreed
found bugs
IDOR
Weak password reset
Business logic flaw
publicly accessible configuration files
some p5
The website is an E-commerce site and my tools for enumerations are subfinder, gau, nuclei, httpx and paramspider. After finishing my enumeration i found some configuration files and some non existing directories so i used ffuf and explore the site.
After registering an account i noticed that the password policy is not strong which will be considered as p5 and also there was no rate limiting. Theres also a file upload i tried bypassing the filter upload but i failed also the exif data is being stripped and i proceed to find another bug.
IDOR
after buying an item it will be shown on the history and you can view it. After opening the network tab i noticed that its trying to fetch an item followed by a number which would likely to be prone to IDOR
after intercepting it with burp and changing the value it was a success
it leaks lots of information about the customer including their receipt of payment, billing addresses and etc in other term we got a personally Identifiable Information (PII) and checking the bugcrowd taxonomy they consider this as P1 I might be wrong for this since im quite new to bug bounty.
checking for more what does the response have it also have the image link for their payment receipt.
weak password reset implementation
looking for more and common bugs i tried the reset password functionality. after checking it on burp it leaks some token and this would be considered as p4 based on bugcrowd taxonomy
checking the email i received the application goes by https://redacted.com/reset-password/<token>/<email address> but the token was different and i thought this would not work but.
after entering the token i intercepted from burp it still redirects me to password change. as you can see the email token starts at 6e2…..a50 and the token from burp was XKJ……Y9H.
This made me realize that from the IDOR vulnerability and this weak password reset implementation could be chain together to get much more security impact.
Same thing with their admin panel it shows the token from burp and a little bit of recon you could get a possible admin email i did not test the admin panel since i dont own that account and i should not test on accounts that i dont own.
also upon checking the login functionality theres also no rate limiting and it was prone to brute force attacks but this would likely to be considered as p5 if theres also an IP block we could just use IP rotation from burp extension or make our own script to bypass the IP block.
business logic flaw
next bug i found was a business logic flaw on purchasing an item where in i can buy an item for free or in unexpected price
i tried buying the highest priced item that costs around 65,990 and with a total cost of 66,240. clicking to substract the quantity doesnt allow me to do but adding more quantity is allowed
intercepting the request on burp i could manipulate the quantity only.
adding a quantity as 0 the total amount changed to 251 now its much more cheaper and i can buy an item that costs around 65 990 for a total price of 251. Reloading the website the total amount remain the same with a value of 251
after completing the transaction i was able to buy it and i reported this since i dont want the item to be shipped.
later on i got an email telling that my order was cancelled and it has an invoice with same total amount of 251
publicly accessible configuration files
the last bug i found was the webconfig and .htaccess while enumerating. The htaccess was new to me and checking what i could do with it there was a possible RCE, DOS, and etc. i tried a few payloads but didnt work and i think i need more research in order to figure out how the .htaccess works and the exploitation goes by
https://github.com/wireghoul/htshells https://www.acunetix.com/vulnerabilities/web/htaccess-file-readable/ https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/htaccess-file-detected/ https://book.hacktricks.xyz/pentesting/pentesting-web/php-tricks-esp#code-execution-via-.httaccess
References:
https://cwe.mitre.org/data/definitions/840.html (Business logic error) https://cwe.mitre.org/data/definitions/640.html (Weak Password Recovery Mechanism for Forgotten Password) https://cwe.mitre.org/data/definitions/639.html (Insecure Direct Object Reference)
https://cwe.mitre.org/data/definitions/287.html (htaccess and web configuration)
https://github.com/wireghoul/htshells https://www.acunetix.com/vulnerabilities/web/htaccess-file-readable/ https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/htaccess-file-detected/ https://book.hacktricks.xyz/pentesting/pentesting-web/php-tricks-esp#code-execution-via-.httaccess