Broken Authentication | Authentication Bypass by Assumed-Immutable Data; Part 2
After I successfully bypassed the OTP through response manipulation(Explained in Part 1 of this article) on example.not.com, I shifted towards finding vulnerabilities in the Feedback submission form. The form has several input fields, along with this it also has a Captcha(of no use).
I started looking for XSS in the input fields, but to no success, because the input was being sanitized before getting included in the HTML page. 😿
Unsuccessful in finding XSS on this target, I again started analyzing the HTTP traffic after the OTP Authentication Bypass part.
Now we have our web application with a valid authentication token generated for a specific phone number, However, after verifying the OTP, when you click on ‘New Feedback/Complaint’, the web app sends an HTTP POST request which only contains the phone number, and in response, the server returns the feedback form auto-populated with some saved information(Phone Number, Name, Email, State, user Feedback field, Application No., and some other sensitive Personal Identification Numbers [e.g., social security number (SSN), passport number, driver’s license number, taxpayer identification number, patient identification number, financial account number, or credit card number]) associated with that particular phone number.
**This received feedback form also contains a Captcha but due to improper implementation, it is not able to rate limit the number of requests.
Also, after verifying the OTP, when you click on ‘New Feedback/Complaint’, the server doesn’t verify if, in the HTTP POST request, you have provided an actual phone number or any 10-digit integer string. Hence you can tamper this request parameter and enter any 10-digit integer string.
Exploit Scenario 1: Due to failure in OTP authentication of a phone number and improper captcha implementation in example.not.com, you can create n number of New Feedback/Complaints from anyone’s phone number.
Exploit Scenario 2: You can paste n number of Feedback/Complaint from any arbitrary integer string of 10 digits, or using a number not registered on the web app.
*I was able to post more than 700 feedbacks/complaints in less than 2 minutes. what makes this an issue is that there is a dedicated team responsible for reading and resolving each feedback with a proper response to the feedback provider along with this they need to answer management about the high number of complaints.
example.not.com had several flaws which collectively made it very vulnerable. It has the potential to become a DVWA ;-) . Identified vulnerabilities were categorized under A04:2021 — Insecure Design/Implementation and A07:2021 — Identification and Authentication Failures (OTP & Captcha Failure leading to No rate Limiting and OTP bombarding, PII Leakage, Broken Authentication, CWE-302: Authentication Bypass by Assumed-Immutable Data)
🙏🏼
