2FA bypass

Flawed two-factor verification logic Sometimes flawed logic in two-factor authentication means that after a user has completed the initial login step, the website doesn't adequately verify that the same user is completing the second step. For example, the user logs in with their normal credentials in the first step as follows:
```
POST /login-steps/first HTTP/1.1 
Host: vulnerable-website.com 
... 
username=carlos&password=qwerty
```

They are then assigned a cookie that relates to their account, before being taken to the second step of the login process:

HTTP/1.1 200 OK 
Set-Cookie: account=carlos

GET /login-steps/second HTTP/1.1 
Cookie: account=carlos

When submitting the verification code, the request uses this cookie to determine which account the user is trying to access:

plaintextCopy codePOST /login-steps/second HTTP/1.1 
Host: vulnerable-website.com 
Cookie: account=carlos 
... 
verification-code=123456

In this case, an attacker could log in using their own credentials but then change the value of the account cookie to any arbitrary username when submitting the verification code.

plaintextCopy codePOST /login-steps/second HTTP/1.1 
Host: vulnerable-website.com 
Cookie: account=victim-user 
... 
verification-code=123456

Clickjacking on 2FA Disable Feature
1. Try to iframe the page where the application allows a user to disable 2FA.
2. If iframe is successful, try to perform a social engineering attack to manipulate the victim to fall into your trap.
Response Manipulation
1. Check Response of the 2FA Request.
2. If you observe "Success":false, change this to "Success":true and see if it bypasses the 2FA.
Status Code Manipulation
1. If the Response Status Code is 4XX like 401, 402, etc.
2. Change the Response Status Code to "200 OK" and see if it bypasses the 2FA.
2FA Code Reusability
1. Request a 2FA code and use it.
2. Now, re-use the 2FA code and see if it is used successfully—that's an issue.
3. Also, try requesting multiple 2FA codes and see if previously requested codes expire or not when a new code is requested.
4. Also, try to re-use the previously used code after a long time duration, say 1 day or more. That will be a potential issue as 1 day is enough duration to crack and guess a 6-digit 2FA code.
CSRF on 2FA Disable Feature
Backup Code Abuse Apply the same techniques used on 2FA such as Response/Status Code Manipulation, Brute-force, etc., to bypass Backup Codes and disable/reset 2FA.
Enabling 2FA Doesn't Expire Previous Session
1. Login to the application in two different browsers and enable 2FA from the 1st session.
2. Use the 2nd session, and if it is not expired, it could be an issue if there is an insufficient session expiration issue. In this scenario, if an attacker hijacks an active session before 2FA, it is possible to carry out all functions without a need for 2FA.
2FA Refer Check Bypass
1. Directly navigate to the page that comes after 2FA or any other authenticated page of the application.
2. If there is no success, change the Refer header to the 2FA page URL. This may fool the application into pretending that the request came after satisfying the 2FA condition.
2FA Code Leakage in Response
1. At the 2FA Code Triggering Request, such as Send OTP functionality, capture the Request.
2. See the Response of this request and analyze if the 2FA Code is leaked.
JS File Analysis
1. While triggering the 2FA Code Request, analyze all the JS Files that are referred to in the Response to see if any JS file contains information that can help bypass 2FA code.
Lack of Brute-Force Protection This involves all sorts of issues which come under security misconfiguration such as lack of rate limit, no brute-force protection, etc.
1. Request a 2FA code and capture this request.
2. Repeat this request for 100-200 times, and if there is no limitation set, that's a rate limit issue.
3. At the 2FA Code Verification page, try to brute-force for valid 2FA and see if there is any success.
4. You can also try to initiate requesting OTPs on one side and brute-forcing on the other side. Somewhere the OTP will match in the middle and may give you a quick result.
Password Reset/Email Change - 2FA Disable Assuming that you are able to perform an email change or password reset for the victim user or make the victim user do it by any means possible. 2FA is disabled after the email is changed or the password is reset. This could be an issue for some organizations. However, it depends on a case-by-case basis.
Missing 2FA Code Integrity Validation
1. Request a 2FA code from the Attacker Account.
2. Use this valid 2FA code in the victim's 2FA Request and see if it bypasses the 2FA protection.
Direct Request
1. Directly navigate to the page that comes after 2FA or any other authenticated page of the application.
2. See if this bypasses the 2FA restrictions.
3. Try to change the Referrer header as if you came from the 2FA page.
Reusing Token Maybe you can reuse a previously used token inside the account to authenticate.
Sharing Unused Tokens Check if you can get the token from your account and try to use it to bypass the 2FA in a different account.
Leaked Token Is the token leaked in a response from the web application?
Session Permission
1. Using the same session, start the flow using your account and the victim's account.
2. When reaching the 2FA point on both accounts, complete the 2FA with your account but do not access the next part.
3. Instead of that, try to access the next step with the victim's account flow.
4. If the backend only sets a boolean inside your session saying that you have successfully passed the 2FA, you will be able to bypass the 2FA of the victim.
Password Reset Function In almost all web applications, the password reset function automatically logs the user into the application after the reset procedure is completed.
1. Check if a mail is sent with a link to reset the password and if you can reuse that link to reset the password as many times as you want (even if the victim changes their email address).
Lack of Rate Limit Is there any limit on the number of codes that you can try? Can you brute force it? Be careful with a possible "silent" rate limit—always try several codes and then the real one to confirm the vulnerability.
Flow Rate Limit but No Rate Limit In this case, there is a flow rate limit (you have to brute force it very slowly: 1 thread and some sleep before 2 tries) but no rate limit. So with enough time, you can find the valid code.
Re-send Code and Reset the Limit There is a rate limit, but when you "resend the code," the same code is sent and the rate limit is reset. Then, you can brute force the code while you resend it so the rate limit is never reached.
Client-Side Rate Limit Bypass
Lack of Rate Limit in the User's Account Sometimes you can configure the 2FA for some actions inside your account (change mail, password, etc.). However, even in cases where there is a rate limit when you tried to log in, there isn't any rate limit to protect actions inside the account.
Lack of Rate Limit Re-sending the Code via SMS You won't be able to bypass the 2FA, but you will be able to waste the company's money.
Infinite OTP Regeneration If you can generate a new OTP infinite times, the OTP is simple enough (4 numbers), and you can try up to 4 or 5 tokens per generated OTP, you can just try the same 4 or 5 tokens every time and generate OTPs until it hits.
2FA Off, but Bypassing the OTP Only Try to disable 2FA on the account and see if it generates the valid OTP without needing 2FA to be on.

PreviousChecklists Nextadmin panal

Last updated 2 months ago