MFA Bypassing Techniques to earn ($$$$) Bounty
Hello Security Folks.
I am Jainam Jain running a community of Shuttlertechsecurity and Active reader, researcher & Senior Cyber Security Analyst & Trainer.
I am trying to provide you with a series of attacking methodologies through my research over medium and different platforms & practical Bypassing techniques. My resources will be from different platforms and my own practical approach and learning.
What is MFA
The addition of Multi-Factor Authentication (MFA), commonly referred to as Two-Factor Authentication (2FA), to an application increases the account’s overall security.
Multi-Factor Authentication Workflow
1. The user accesses the Application’s Login Function and enters their login credentials.
2. The application then initiates a 2FA request, prompting the user to enter and verify their identity a second time. This is not the same as the password.
3. The user has access to his or her 2FA device, which could be a Third-Party Application (TPA) such as Authy or Google Authenticator.
4. The user enters the 2FA code into the 2FA request, and the application logs in successfully if the code is valid.
I’ll go over how to get around Multi-Factor Authentication in a variety of ways (assuming at least one of them works) and how to possibly fix each scenario (for devs).
Techniques for Bypassing Multi-Factor Authentication
1. Manipulation of the HTTP Response Body
When the application fails to validate the response check and proceeds to the next step, this is one of the most common and widely used techniques for bypassing MFA. Assume an application checks whether the given OTP is valid and returns {“success”: true} if it is, otherwise {“success”: false}. At the same time, the application only checks to see if the response is {“success”: true} before proceeding. In this case, an attacker can intercept the response and change the status from false to true, effectively bypassing MFA.
Original Request with Invalid OTP:
POST /otp-verify
HOST: evil.com
<redacting_required_headers>{"otp":1234}Original Response:
200 OK
<redacted>{"success":false}Modified Response (with the 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 previously described technique, if the application relies on checking the HTTP Response Status Code before proceeding, it is possible to manipulate the response code and circumvent the restriction.
Original Request with Invalid OTP:
POST /otp-verify
HOST: target.com
<redacting_required_headers>{"otp":1234}Original Response:
403 Forbidden
<redacted>{"error":true, "message":"Unverified}Modified Response — Status Code(with same wrong OTP):
200 OK
<redacted>{"success":true}3. Cached OTP in Dynamic Java Script Files
The application may use dynamic JavaScript files to store a copy of the OTP, which is then compared to the OTP received by the user to perform the client-side check and validate the user. This situation is frequently overlooked, but it can be exploited by carefully inspecting the JavaScript files. The typical procedure is as follows:
a. The attacker goes to https://shuttler.tech/forgetpass.php, enters the victim’s email address, and requests an OTP for a password reset.
b. The attacker intercepts this request and looks for JavaScript files in the response body.
c. Assume there is a javascript file present, such as /a5.1234.app.js.
d. The attacker will now scrape this Javascript file to see if the OTP is stored in plain text/encrypted form, and if any information to circumvent the OTP can be obtained.
e. If the OTP is stored, it can be used as a valid OTP, and the victim’s OTP restriction can be bypassed without user interaction.
4. Forced Browsing/Direct Request
This problem occurs when the application lacks or improperly implements authorization checks. Assume the application’s workflow is as follows:
a. The user goes to www.Shuttler.tech/login.php and enters their login information.
b. The application redirects the user to www.Shuttler.tech/mfa.php and requests an OTP.
c. When a valid OTP is entered, the user is redirected to the www.Shuttler.tech/profile.php page and can access other parts of the application.
Now, The attacker user would be able to do the following if the program has insufficient authorization checks:
a. The user inputs their login information at www.Shuttler.tech/login.php.
b. The user is redirected to the www.Shuttler.tech/mfa.php page where they are prompted to enter their OTP.
c. The user now navigates directly to www.Shuttler.tech/profile.php instead of entering the OTP, and if the user is successful in accessing the /profile.php page, the MFA requirement is disregarded.
5. Disabling MFA using CSRF & Clickjacking
Assume there is no password or authentication verification on the application and that approved users have the ability to turn off MFA. In the event that the application is also susceptible to CSRF or Clickjacking, the attacker may use these techniques to convince the target user to disable MFA and remove the blocker while using the compromised credentials to access the victim account.
6. Response Code Leakage
When initiating an OTP request, the application may leak the OTP somewhere in the response body. It is always a good idea to read the response body and determine if there is any potential leakage that could lead to the MFA being bypassed.
These are some of the most common and interesting techniques for bypassing MFA, but they are not exhaustive. More techniques are mentioned in the MindMap, such as Backup Code Abuse, in which all of the above test cases can be applied to the Backup Code, which is used to reset the MFA. There are some other MFA bypassing techniques that are less effective or require more user interaction and thus are not covered in this article.
7. Reusability of OTP Codes
When the application does not invalidate a previously used OTP and the expiration time-frame is significant, such as one day. An attacker can use it to brute-force or guess a valid (even complex) OTP and circumvent the restriction. The following steps can be taken to determine whether or not this problem exists:
a. The attacker requests and uses an OTP.
b. In the following iteration, the attacker uses the same old OTP, and if the OTP is accepted as valid, the issue persists.
8. Inadequate Brute-Force Protection for OTP Validation
Due to a lack of throttling and missing rate limiting/brute-force protection, the following (not exhaustive) attacks are possible:
a. If a weak OTP is used, such as a 4-digit OTP with no brute-force protection, it can be easily bypassed.
b. If the rate-limiting and brute-force protections are absent but the OTP is strong, say it’s a 7-digit OTP. In this case, a Meet-In-The-Middle attack is possible. Where the attacker will request new OTPs while also performing brute forcing. The OTP will match somewhere for an instance and will be able to bypass the restriction.
c. If there is no rate limiting, an attacker can send n number of OTPs to the victim user (irrelevant to 2FA bypass but still an attack).
9. OTP Integrity Checks Are Missing
This is a straightforward attack. This can be used when the application only checks for a valid OTP but does not check for which user. The steps are straightforward:
a. The attacker asks for a valid OTP from his account.
b. The attacker logs in to the Victim's account using the request OTP from his account.
c. If the application does not perform which user the OTP is valid for, but simply checks if the OTP is valid or not, this can be used to circumvent the MFA restriction.
It is strongly advised that you read up on these techniques by searching for HackerOne/Bugcrowd Disclosed Reports and Medium Articles.
Remediations
1. Ensure that no OTP verification logic occurs on the client side and that no OTP/OTP generation logic is stored on the client side.
2. Ensure that the OTP is not leaked in the server’s response body.
Check that the application performs integrity checks and that the valid OTP is coming from which user.
3. Ensure that all authorization checks are in place and that the user cannot bypass the MFA page by directly requesting the authenticated endpoint after providing a valid login password.
4. To avoid potential bypass, ensure that the application does not rely on the response status code or response body returned by the server and that it properly validates against response manipulation.
5. Check that the application performs integrity checks and that the valid OTP is coming from which user.
Make sure the OTP cannot be reused and that the expiration time is short, such as 15 minutes.
6. Ensure that a strong OTP is used and that the application has proper brute-force and rate-limiting protections in place.
7. Make sure the MFA Disabling feature requires a user to verify the password in order to prevent the attacker from disabling MFA if they try to chain it with issues like Clickjacking or CSRF.
Takeaways
- Understanding the various methods for circumventing MFA
- Reading Dynamic Javascript to determine OTP Generation Logic or OTP Stored on the Client Side.
- Checking for Incomplete Integrity Checks
- Using Response Code and Response Body Manipulation to Avoid MFA
- Performing a variety of MFA Bypasses
- Resolving Attack Vectors to Prevent MFA Bypass
- understand the Flow of MFA Working.
Thank you for reading my post; please leave any questions or resources in the comments section below. Also, don’t forget to look at the 2FA Bypass Techniques Mindmap & Subscribe Youtube Channel to see such Live POCs “https://www.youtube.com/channel/UCS7EGEUlV6Sr7VUnzhBBZrg”
