OTP Bypass Using Tricky Way
In today’s world, everything we do on the internet requires Authentication.
And in ancient days, It was the “username: password” way of doing it, then came to the new world where we use OTP.
Today, authentication is necessary for every online action we do.
And back in the day, the procedure was “username: password,” but then the OTP era came along.
OTP stands for One Time Password, but what if it’s not really a one-time password?
There are a number of methods that the developers may implement this OTP without checking certain logical assumptions.
Let’s list each flaw and then talk about it separately.
- Reusability of OTP.
- Brute Force OTP.
- Bypass OTP.
Let’s now examine the aforesaid vulnerabilities in more detail from the standpoint of security.
- OTP Reusability: In this scenario, the OTP, once used, never expires, allowing us to log in several times with the same OTP.
- OTP Brute Force: In this instance, the OTP can be brute forced using any automated tools, such as burp or any script, to attempt all possible OTPs. Although this process appears to take a very long time, it can be completed rapidly by using multithreading and licensed versions of some programs.
- OTP Bypass: Well, this is a complex situation, and it may differ in each application. I have personally discovered more than three techniques to get around OTP.
How to get around OTP (a Few Examples):
In some applications, the developer solely relies on the server answer rather than on the OTP the user sends. Okay, let’s go into detail with an illustration: Consider a scenario in which the application transmits OTP 1234, but the hacker is unaware of the OTP. However, he would intercept the response using a proxy tool and replace it with the response he got when he attempted his real mobile phone number and real OTP. In some circumstances, it’s extremely simple; the response when the OTP is incorrect looks like this:
Connection: Upgrade, Close
X-UA-Compatible: IE=edge
Content-Type: application/json
Content-Length: 7
“False”
However, the Hacker can easily change the false flag to true. below is the response in the burpsuite.
Connection: Upgrade, Close
X-UA-Compatible: IE=edge
Content-Type: application/json
Content-Length: 7
“true”
Well, it could get tricky; in some cases, the server may also be checking other parameters such as content length, etc. So it’s a conventional approach that varies depending on the developer.
2. Let’s take a different approach. In a recent incident, I used the OTP reusability vulnerability to brute force, but it was challenging.
In contrast to the first instance, this application was actually checking the OTP.
In contrast to the earlier case, this application was actually checking the OTP. The problem was that every time I resent the OTP, I received the same OTP and it stated that it would expire in 8 minutes. When I used the same OTP from the app, it worked, but when I used the same OTP from the repeater tab in my Burp suite tool, with the old OTP Validation request, It said OTP expired. I then had to figure out what the variable was if the OTP was constant, but the server isn’t letting me authenticate for some reason.
After carefully examining the request, we discovered one parameter that was dynamic and dependent on the value returned in the response when we used the Resend OTP Application programming interface.
To summarise, first use the Resend OTP API, then get the parameter from the response and brute force it. And after every three attempts, we must change the parameter that we received from the Resend OTP API response.
So there are two options. You can either go manually with an intruder or write a Python script that will try all the numbers from 0000 to 9999, but remember that after every third attempt, it will hit the Resend OTP API, get the parameter from the response, use that parameter with the next three attempts, and repeat the process for the remaining three attempts.
It will look like this:
First, get the parameter and use it to send the OTP validation API and try 1111, 1112, 1113, then hit Resend OTP API, get the parameter value, and use it to send the OTP Validation request and try 1114, 1115, 116 until you get the 200 Ok response, and then use that parameter and OTP to login.
So, OTP Bypass is a little tricky, but the developers may always surprise you with their coding skills.
Best practices for OTP are as follows:
1. Enable OTP expiry.
2. Implement both client and server-side OTP verification, rather than just response verification.
3. After 3 or 5 unsuccessful attempts, discard the OTP and send a new OTP to try again.
Subscribe to see live POC video: https://www.youtube.com/channel/UCS7EGEUlV6Sr7VUnzhBBZrg