Exploiting OTP Features for Account Takeover Vulnerability

In this article, we will see how I was successfully able to manipulate the authentication process of an application, allowing me to bypass the login feature and takeover any users account.

Introduction :
Hello guys! I am Avanish Pathak, I am a student currently perusing my Computer Science degree and I am an active Bug Bounty hunter. Today I would like to share one of my findings that I came across on one of the private programs, where I was able to gain access to any user’s/employee’s account of that application.

Brief about what is an Account takeover vulnerability?
This is a type of vulnerability that allows an attacker to gain an unauthorized and full control of the victim’s account without any need of credentials by exploiting the authentication flaw existing in the application.

Attack Scenario
The application had a login with OTP functionality, that allowed the user to login by entering the 4 digit OTP sent to the registered email as part of its authentication flow.

As it was just a 4 digit OTP first thing that came to my mind was to Brute force the OTP and login to the victim’s account, which is likely the first thing that comes to mind when looking at a short OTP.

I also checked weather if the OTP is leaked in the response which i came across in my previous finding related to account takeover vulnerabilities.

I noticed that the application was giving ​ HTTP ​ 429 Too Many Requests ​ response after 10 wrong attempts which means there was a rate limiting mechanisms in place also i didn’t find any OTP shared in the response so no luck :(

I decided to dig more deeper into this and taking a close look at the authentication flow I observed that when you enter a correct OTP the ​ POST​ request issued at ​ /login/signin ​ looked somewhat like this:

{“ email ”:“usermail@gmail.com”,“code”:XXXX } ​ CORRECT OTP

The ​ POST​ request consisted of two parameters, which are the email address of the user and the OTP sent to that email address providing which one could successfully login to his account.

I noticed that when the ​ /login/signin ​ request is captured and changing the email parameter to any existing higher privileged user’s email with a correct OTP (​ sent to attacker’s email address ​ ) combination looked somewhat like this :-
{“ email ”:“admin@example.com”,“code”:XXXX } ​ CORRECT OTP

By performing this action I was able get logged into any valid user’s account in the application, this was a case of loose coupling of email with the OTP.

I immediately went ahead and reported this vulnerability and it was Triaged and Fixed within 24 hours.

The fix implemented was that the Email parameter was removed from the ​ /login/signin ​ request and there was a check in place that validated the OTP sent to the user trying to login.

The vulnerability existed because there was no check implemented for the valid issuer’s email. The application was only validating the OTP sent from the back-end hence providing a valid OTP with any changed email address gets you logged into the account registered with that email and you have complete access over it.

Hope you guys enjoyed it!
For any queries hit me up on Twitter:​ ​ https://twitter.com/avanish46
Until next time Cheers !! :)