2FA broken logic

This lab's two-factor authentication is vulnerable due to its flawed logic. To solve the lab, access Carlos's account page.

• Your credentials: wiener:peter

• Victim's username: carlos

Analysis:

Step 1: Observing the Authentication Process

1. The first request is a POST request to /login with the username and password.

   

   2. The second request is a GET request to /login2 that triggers the 2FA token.

      • This request contains a cookie named verify, which holds the username.

      • Issue: The server determines which user gets the 2FA code based on this cookie rather than a secure backend check.

        

Step 2: Retrieving Carlos's 2FA Code

1. Capture the GET /login2 request after logging in as wiener:peter.

2. Modify the verify parameter from wiener to carlos.

3. Resend the request to trick the system into generating a 2FA code for Carlos.

4. Open the email client and check for Carlos’s 2FA code.

   Here, which takes the 2mfa code where still gives us the user and session , if we remove the session the response still gives us 200ok / account page which means we still no need a valid session all we need is the correct MFA code over here the username and password is actually not required which is good because i don't have Carlos's password so now all i have do to is guess the Carlos's MFA code

   

   

   And here Email Client:

   

Identifying the Vulnerabilities

1. Flawed 2FA Implementation:

   • The verify cookie parameter dictates where the 2FA code is sent.

   • Changing verify=wiener to verify=carlos triggers a 2FA code for Carlos.

     

2. Session Mismanagement:

   • Removing the session token still allows access to the 2FA code request.

     

     Here, the system still returns the user and session while taking the 2FA code. If we remove the session, the response still gives us a 302 redirect to the account page. This means we do not need a valid session—all we need is the correct MFA code. The username and password are actually not required, which is advantageous since we do not have Carlos's password. Now, all we need to do is guess Carlos's MFA code.

     First, I changed the verify parameter to carlos and observed the response. Hitting enter, I received a 200 OK response with a message stating that the security code was incorrect. This confirms that I only need to determine Carlos's MFA code.

     

     

     Additionally, after sending multiple incorrect 2FA attempts (more than five times), I noticed that the system did not log me out. This indicates that there is no brute-force protection, making it easy to guess the correct 2FA code.

     

3. Brute Force Protection Missing

   • The system does not block multiple incorrect 2FA attempts.

   • This allows brute-forcing the 4-digit 2FA code (10,000 possibilities).

Conclusion

This challenge highlighted critical authentication flaws:

• Trusting client-side parameters (verify cookie) for security decisions.

• Poor session management allowing unauthorized access.

• Lack of brute-force protection, making 2FA easy to bypass.

By exploiting these weaknesses, we successfully accessed Carlos’s account and completed the lab.

Why This Methodology?

This approach systematically identifies weaknesses in the authentication mechanism by analyzing how the application processes 2FA. Instead of traditional credential stuffing, the method leverages logical flaws that bypass security controls without requiring password compromise.

Unique Tips:

1. Look for Client-Controlled Parameters: Always check if authentication mechanisms rely on user-controlled cookies, headers, or parameters. Manipulating these can expose logic flaws.

2. Test Session Dependency: Remove session cookies during authentication steps to see if access persists, revealing improper session handling.

3. Check for Brute Force Protection: If a 4-digit or 6-digit OTP system is in place, verify whether multiple failed attempts lock the account. If not, brute-force attacks become viable.

4. Use Burp Suite Macros: Automate multi-step processes like logging in, modifying parameters, and checking responses dynamically.

5. Always Verify Response Codes: A 302 redirect instead of a 401 Unauthorized might indicate authentication bypass potential.

By combining these techniques, we were able to successfully bypass 2FA and access Carlos’s account without knowing his actual credentials.

#CTF #CyberSecurity #2FABypass #BurpSuite #WebSecurity #EthicalHacking #portswigger.net