Behind the Scenes: Discovering an OTP Leakage Bug in a Leading Broadband Service’s Website

When I recently relocated to a new city and rented a house, I was provided with Wi-Fi access that came with certain limitations, such as speed restrictions, device limits, and data usage caps. The property owner had partnered with a prominent broadband service provider, granting Wi-Fi access to all residents. While the rented Wi-Fi offered add-on options to increase number of devices that can be connected parallelly and to add additional data. To do this all there was a management portal, accessing the management portal required a username or mobile number and an OTP. However, as the lease was under my friend’s name, I realized that I would have to ask him for the OTP every time I needed to access the portal. Curiosity sparked my hacker mindset, prompting me to explore if there was a way to bypass the OTP verification and gain unrestricted access.

I began my analysis by examining the source code of the primary login page. During my review of the source code, I identified multiple functions responsible for validating and authenticating user credentials. Of particular interest was the OTP verification function. It came to my attention that this function checkOTP() solely handled the client-side validation of OTPs, which led me to look for the possibility of investigating any potential leakage of OTPs within the HTTP response.

Upon analysis of the checkOTP() function, it became apparent that it compared two variables “sotp” & “otp”, and if they matched, the user was redirected to a usage history page. In the event of a mismatch, an error message was displayed. It was evident that one of the variables was entered by the user, while the other was generated by the server. With this understanding, I proceeded to intercept the HTTP request to verify the presence of the OTP in the response.

Upon analyzing the response, it was discovered that the OTP and the registered mobile number were being leaked. Specifically, the OTP was being transmitted in the response via the “ret” parameter, with the actual OTP value being “5552”.

Thank You for reading. Knowledge is power, so keep gaining! 😈