OTP Bypass through Response Manipulation | A Case of Insecure Design/Implementation; Part 1

Broken Authentication GIF by SUNEET SINGH

One Time Passwords provides a comparatively safe and easy mechanism of signing-in and Identity Authentication, However, if your application relies solely on OTP-based Sign-In/Authentication developers must ensure that applications and their components are securely designed, implemented, and tested for failure. I can't address enough the need for having Application Security testers and integrating Penetration Testing within your SDLC (or following secure SDLC) & CI/CD pipeline.

Target Context: example.not.com is a critical web application(data fiduciary) that handles lots of PII(Personal Identifiable Information) data. There exists a Feedback Portal(example.not.com/service/feedback) to submit feedback, suggestions, or complaints. The application performs only an OTP-based authentication to fetch and allow you to see your previously posted feedback/s. Once authenticated web application also shows the option of posting feedback and uses the same authentication token generated after OTP verification to allow users to post new feedback on the website.

Vulnerability: In my target web app, vulnerability arises due to the improper design and hazardous implementation of the OTP authentication mechanism. example.not.com generates an HTTP POST request for the OTP verification, in which it sends the OTP entered by the user on the web page. In response, the server, after verifying the provided value, returns only a true or a false value for a correct or incorrect OTP respectively. Once the web application receives the boolean value as true, it sends a GET request to fetch feedback details, after which one can see their victim’s previously posted feedback which along with the feedback or complaint also contains the feedback provider’s Full Name, email, state, and other sensitive information(can not be mentioned to protect target’s identity), apart from this the option to post new feedback is also unlocked on the web application.

Impact: A malicious actor can see anyone’s feedback and their stored PII if the user exists. Also due to No Rate Limit, this vulnerability can be exploited for large-scale illegal PII extraction through automation.

POC:

1. Goto vulnerable URL(example.not.com/service/feedback) enter your phone number, and click on ‘Generate OTP’.

Feedback User Authentication form

2. To intercept the response automatically for the intercepted request in BurpSuite, go to ‘Proxy settings’ and in the proxy settings page, under ‘Response interception rules’, first check the box for ‘Intercept responses based on the following rules:’, then enable the option to intercept response if the request ‘Was intercepted’(highlighted in the screenshot).

Burp Suite response interception settings

3. Now enter any random 6-digit number and intercept the ‘Authenticate’ request.

Authentication Form

3. Below is the Original HTTP POST request and response for OTP authentication.

Original Request and corresponding response

4. Below is the request and modified boolean response.

Edited Response with the highlighted vulnerable value

I defined this vulnerability under Broken Authentication caused by Insecure Design/Implementation in the submitted report. Due to this OTP authentication failure I was also able to post feedback from anyone’s mobile number, In fact, after initial OTP authentication through that boolean value, the web application and even the server was not authenticating any requests for inconsistency in data leading to ‘CWE-302: Authentication Bypass by Assumed-Immutable Data’, explained in Part2.

🙏