Recently, we tested a mobile application of a BFSI platform, which allowed the organization's employees to view and interact with new customer leads.
The mobile app had a password-based authentication system, with the username being the mobile number of the user. We identified a major weakness in this mobile app.
The app allows a user to reset the password if they can prove themselves via an OTP. When the 'forgot password' button is pressed, the user is sent to a page where they are prompted to enter an OTP. The OTP is sent to the phone number, and if the wrong OTP is entered, the server responds with `{"OTP":"Failure"}`. While this seems to have been implemented properly, we tried to change the server response by conducting an MITM. We changed the response from the server to `{"OTP":"Success"}`. This redirection led us to the password change screen, where we were prompted to enter a new password.
Initially, we believed this was only a visual bug and that the password reset would fail. However, we soon discovered that the password reset page itself does not check the OTP, and there is no session to track the successful OTP. This means any attacker can take the password change request, replace the phone number, and change the password of any other user (phone number). In simple terms, the OTP verification and the password reset page are not connected. The password reset API call did not have any verification or authentication to ensure only the correct user can change the password.
This reveals how BFSI developers, when asked to build an app, often create the requested features without considering any security architecture. These apps are usually rushed, and only the positive/happy paths are checked. Security testing and architecture are often considered only as an afterthought. Unless BFSI incorporates security architecture into the development stage itself, such vulnerabilities will continue to emerge.
By
Suriya Prakash
Head DARWIS
CySecurity Corp
