Multi-Factor Authentication (MFA) often known as Two-Factor Authentication (2FA) is an added layer of protection added to an application in order to enhance the overall security of the user’s account.
Multi-Factor Authentication Workflow
- The user navigates to the Application’s Login Function and provides login credentials.
- Upon which, the application invokes a 2FA request, asking the user to input and verify the identity for a second time. This is different from the password.
- The user has access to its 2FA device, say, it’s a Third-Party Application (TPA) like Authy or Google Authenticator.
- The User takes the 2FA code and provides it to the 2FA request and upon valid code, the Application logs in successfully.
In a nutshell, Even if a user is compromised and the attacker has the login credentials, it would be a challenge to verify the second identity in order to successfully log in to the application. If it’s a fail, there is no use in having the user’s login credentials. (Hacker’s sobbing in the corner)
Hi Fellow Penetration Testers, Security Enthusiasts, & Ethical Hackers,
In this blog, I’ll discuss how to bypass Multi-Factor Authentication using multiple ways (assuming at least one will work) and how to possibly remediate each scenario (for devs).
A couple of weeks back, during my #learn365 challenge on the very first day, I attempted to bypass Two-Factor Authentication in multiple applications. During this, I gathered a lot of information from public sources and my experience to create a handy mindmap talking about how to Bypass Two-Factor/Multi-Factor Authentication in multiple ways. You can find the original Mindmap here.
In the next section, we will discuss some important Two-Factor Authentication Bypass Techniques and how to perform them.
Multi-Factor Authentication Bypass Techniques
1. HTTP Response Body Manipulation
This is one of the most common and widely found techniques to bypass MFA when the application fails to validate the response check and proceed to the next step. Let’s assume a scenario where an application checks whether the given OTP is valid, if yes, it returns {“success”:true} otherwise {“success”:false}. At the same time, the application only checks if the response returned is {“success”:true} in order to proceed further. In this scenario, an attacker can intercept the response and change the status from false to true and bypass MFA.
Original Request with Invalid OTP:
POST /otp-verify
HOST: target.com
<redacting_required_headers>
{"otp":82693}
Original Response:
200 OK
<redacted>
__ {"success":false}__
Modified Response (with same wrong OTP):
200 OK
<redacted>
{"success":true}
If the application successfully logs in, it implies that the bypass was successful.
2. HTTP Response Status Code Manipulation
Similar to the above-described technique, if the application relies upon checking the HTTP Response Status Code for proceeding further, it is possible to manipulate the response code and bypass the restriction.
Original Request with Invalid OTP:
POST /otp-verify
HOST: target.com
<redacting_required_headers>
{"otp":82693}
Original Response:
403 Forbidden
<redacted>
{"error":true, "message":"Invalid Token"}
Modified Response — Status Code(with same wrong OTP):
200 OK
<redacted>
{"success":true}
3. Direct Request/Forceful Browsing
This issue happens when the application lacks authorization checks or doesn’t properly implement them. Suppose the application has the following workflow:
*a. The user navigates to www.harshbothra.tech/login.php and enters the login credentials. b. The application redirects the user to the www.harshbothra.tech/mfa.php page and asks to provide OTP. c. Now, when the user provides a valid OTP, the user is redirected to the www.harshbothra.tech/profile.php page and can access other parts of the application as well. *
*Now, if the application is having improper authorization checks, the attacker user would be able to perform the following: a. The user navigates to www.harshbothra.tech/login.php and enters the login credentials. b. The application redirects the user to the www.harshbothra.tech/mfa.php page and asks to provide OTP. c. Now, instead of providing the OTP, the user directly navigates to www.harshbothra.tech/profile.php and if the user is able to access the /profile.php page, the MFA requirement is bypassed. *
4. CSRF & Clickjacking to Disable MFA
Assume that the application has functionality for authenticated users to disable the MFA and there is no password/authentication verification on it. Assuming that if the application is also vulnerable to Cross-Site Request Forgery (CSRF) or Clickjacking, the attacker can utilize these attacks to trick victim user to turn off their MFA and remove the blocker & use the compromised credentials to access the victim account.
5. Cached OTP in Dynamic JS Files
Sometimes the application uses dynamic JavaScript files to store a copy of OTP, which is matched against the OTP received by the user to perform the check on the client-side and validate the user. This situation is often ignored but can be leveraged by carefully examining the JavaScript Files. The usual steps are as following:
a. The attacker navigates to https://harshbothra.tech/forgetpass.php page, Input the victim's email, and request OTP for a password reset. b. The attacker captures this request and analyzes the response body for JavaScript Files. c. Assume that there is a javascript file present like the following: /a4.13238.app.js d. Now, the attacker will scrape this Javascript file to see if the OTP is stored in plain text/encrypted form or any information to bypass the OTP can be obtained. e. If there is the OTP stored, it can be used as the valid OTP, and without user interaction victim’s OTP restriction can be bypassed.
6. Missing Integrity Checks on OTP
This attack is fairly simple. When the application just checks for a valid OTP but doesn’t check valid for which user, this can be leverage. Steps are as simple as the following:
a. Attacker requests a valid OTP from his account. b. Attacker uses the request OTP of his account to login to the Victim account. c. If the application doesn’t perform for which user the OTP is valid but just check if the OTP is valid or not, this can be leveraged to bypass the MFA restriction.
7. Missing Brute-Force Protection on OTP Validation
Due to lack of throttling and missing rate limiting/brute-force protection, it is possible to perform the following (not limited to these) attacks:
a. If a weak OTP is used, for example when a 4-digit OTP is used and there is no brute-force protection, it can be bypassed easily. b. If the rate-limiting & brute-force protections are missing but the OTP is not weak, say it’s a 7-digit OTP. In this case, a Meet-In-The-Middle attack can be carried out. Where the attacker will parallelly request for new OTPs and also run the brute-forcing. Somewhere the OTP will match for an instance and can bypass the restriction. c. If there is no rate limiting, an attacker can spam the victim user with n no. of OTPs (irrelevant to 2FA bypass but still an attack).
8. OTP Code Reusability
When the application doesn’t invalidate a previously used OTP and the expiration time-frame is considerable say 1 day. It can be abused by an attacker to brute-force or guess for a valid (even complex) OTP and bypass the restriction. To check if this issue is present, the following steps can be carried out:
a. Attacker requests an OTP and uses it. b. Now, in the next iteration, the attacker uses the same old OTP and if the OTP is accepted as valid, the issue is present.
9. Code Leakage in Response
Sometimes the application leaks the OTP somewhere in the response body while initiating a request for OTP. It is always a good idea to read the response body and understand if there is any possible leakage that can lead to bypassing the MFA.
These are some of the most common and interesting techniques to Bypass MFA, however, not really limited to these. I have mentioned more techniques in the MindMap such as Backup Code Abuse where all the above test cases can be applied on Backup Code which is used to reset the MFA. There are also some other MFA bypassing techniques as well which are less impactful or require more user interaction, hence not covered as part of this blog post.
It is highly recommended to read more about these techniques by searching for the HackerOne/Bugcrowd Disclosed Reports and Medium Articles.
Remediations
- Ensure that the OTP verification logic is not happening at the client-side and OTP/OTP Generation Logic is not stored on the client-side.
- Ensure that the OTP is not leaked in Response Body returned from the Server.
- Make sure the application performs the integrity checks and check for From which user the valid OTP is coming.
- Ensure that the OTP can not be reused and the expiration time is relatively short such as 15 minutes.
- Ensure that the strong OTP is used and the application implements proper brute-force & rate-limiting protections.
- Make sure that the MFA Disabling feature requires a user to verify the password in order to prevent disabling MFA if the attacker tries to chain it with issues such as Clickjacking or CSRF.
- Ensure that all the authorization checks are in place and the user is not able to directly request the authenticated endpoint after providing a valid login password to bypass the MFA page.
- Make sure that the application doesn’t rely upon the response status code or response body returned by the server and properly validates against response manipulation in order to avoid any potential bypass.
Key Takeaways
- Understanding How Multi-Factor Authentication Flow Works
- Understanding the various methods to Bypass MFA
- Reading Dynamic Javascript to find out OTP Generation Logic or OTP Stored at client-side.
- Checking for Missing Integrity Checks
- Performing Response Code & Response Body Manipulation to bypass MFA
- Performing various MFA Bypasses
- Remediating the Attack Vectors to Block MFA Bypass
Thanks for checking out my post, feel free to comment below with any questions or additional resources. And don’t forget to check out the 2FA Bypass Techniques Mindmap here.