Обход двухфакторной

POST /login-steps/first HTTP/1.1 
Host: vulnerable-website.com 
... 
username=carlos&password=qwerty

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

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

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

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  victim to fall in your trap.

1. Check Response of the 2FA Request.
2. If you Observe "Success":false
3. Change this to "Success":true and see if it bypass the 2FA

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 bypass the 2FA

1. Request a 2FA code and use it
2. Now, Re-use the 2FA code and 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 long time duration say 1 day or more. That will be an potential issue as 1 day is enough duration to crack and guess a 6-digit 2FA code.

1. Request a 2FA code and use it
2. Now, Re-use the 2FA code and 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 long time duration say 1 day or  
more. That will be an potential issue as 1 day is enough duration to crack and guess  
a 6-digit 2FA code

Apply same techniques used on 2FA such as Response/Status Code Manipulation,  
Brute-force, etc. to bypass Backup Codes  and disable/reset 2FA

1. Login to the application in two different browsers and enable 2FA from 1st session.
2. Use 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

1. Directly Navigate to the page which 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  
application to pretend as if the request came after satisfying 2FA Condition

1. At 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.

1. while triggering the 2FA Code Request, 
2. Analyze all the JS Files that are referred in the Response 
3. to see if any JS file contain information that can help bypass 2FA code.

This involves all sort of issues which comes under security misconfiguration such as  
lack of rate limit, no brute-force protection, etc.
1. Request 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 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 at one side and brute-forcing at  
another side. Somewhere the OTP will  match in middle and may give you a quick  result

1. Assuming that you are able to perform email change or password reset for the  
victim user or make victim user do it by any  means possible.
2. 2FA is disabled after the email is  changed or password is reset. This could  
be an issue for some organizations.  However, depends on case by case basis.

1. Request a 2FA code from Attacker Account.
2. Use this valid 2FA code in the victim 2FA  Request and see if it bypass the 2FA Protection.

1. Directly Navigate to the page which 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.

1. Maybe you can reuse a previously used token inside the account to authenticate.

1. Check if you can get the token from your account and try to use it to bypass the 2FA in a different account.

1. Is the token leaked on a response from the web application?

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, 
3. complete the 2FA with your account but do not access the next part.
4. Instead of that, try to access the next step with the victim's account flow. 
5. If the back-end only set a boolean inside your sessions saying that you have successfully passed the 2FA you will be able to bypass the 2FA of the victim.

1. In almost all web applications the **password reset function automatically logs the user into the application** after the reset procedure is completed.  
2. 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 his email address).

Is there any limit on the number of codes that you can try, so you can just brute force it? Be careful with a possible "silent" rate limit, always try several codes and then the real one to confirm the vulnerability.

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 be able to find the valid code.

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.

{% content-ref url="rate-limit-bypass.md" %} rate-limit-bypass.md {% endcontent-ref %}

Sometimes you can configure the 2FA for some actions inside your account (change mail, password...). 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.

You won't be able to bypass the 2FA but you will be able to waste the company's money.

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 matches the ones you are using.

If the "remember me" functionality uses a new cookie with a guessable code, try to guess it.

If the "remember me" functionality is attached to your IP address, you can try to figure out the IP address of the victim and impersonate it using the **X-Forwarded-For** header.

If you can find some "testing" subdomains with the login functionality, they could be using old versions that don't support 2FA (so it is directly bypassed) or those endpoints could support a vulnerable version of the 2FA.

If you find that the 2FA is using an API located under a /v*/ directory (like "/v3/"), this probably means that there are older API endpoints that could be vulnerable to some kind of 2FA bypass.

When the 2FA is enabled, previous sessions created should be ended. This is because when a client has his account compromised he could want to protect it by activating the 2FA, but if the previous sessions aren't ended, this won't protect him.

Backup codes are generated immediately after 2FA is enabled and are available on a single request. After each subsequent call to the request, the codes can be regenerated or remain unchanged (static codes). If there are CORS misconfigurations/XSS vulnerabilities and other bugs that allow you to “pull” backup codes from the response request of the backup code endpoint, then the attacker could steal the codes and bypass 2FA if the username and password are known.

If you notice some confidential information appear on the 2FA page that you didn't know previously (like the phone number), then this can be considered an information disclosure vulnerability.

1 access the same account on https://account.grammarly.com in two devices
2 on device 'A' go to https://account.grammarly.com/security > complete all steps to activate the 2FA system
Now the 2FA is activated for this account
3 back to device 'B' reload the page The session still active

Attack scenario :
Attacker sign up with victim email (Email verification will be sent to victim email).
Attacker able to login without verifying email.
Attacker add 2FA.

PoC
1- go to your account and activate the 2FA from /settings/auth
2- after active this option click on Disabled icon beside Two-factor authentication.
3- a new window will open asking for Authentication or backup code - Password to confirm the disabled. 
4- in the first box enter a valid Authentication or backup code and in the password filed enter any random/wrong password and click save.
5- the option will be disabled successful without check the validation of the password.

Steps To Reproduce:
Note: 
1-Use burp suite or another tool to intercept the requests
2-Turn on and configure your MFA
3-Login with your email and password
4-The page of MFA is going to appear
5-Enter any random number
6-when you press the button "sign in securely" intercept the request POST auth.grammarly.com/v3/api/login and in the POST message change the fields:
"mode":"sms" by "mode":"email"
"secureLogin":true by "secureLogin":false
7-send the modification and check, you are in your account! It was not necessary to enter the phone code.

1- Login to Glassdoor and navigate to https://www.glassdoor.com/member/account/securitySettings_input.htm
2- Enable 2FA
3- Logout
4- Login again and notice OTP is asked
5- Now using Burp suite intercept the POST request by sending incorrect code. [Do not forward]
6- Before forwarding the request to server, remove the code and forward
7- Turnoff Intercept and notice that your login request has been fulfilled