Web Application Security: Vulnerabilities in multi-factor authentication PortSwigger Lab Wolkthrough (Part-3).
I’m Subhadip Sardar, a cybersecurity enthusiast with a strong foundation in IT and cybersecurity. I’m passionate about sharing knowledge and empowering the community to build safer digital environments. Currently, I’m creating an in-depth guide to the Vulnerabilities in multi-factor authentication, designed to help others understand and defend against common web security threats. Join me as we explore the world of cybersecurity.
Multi-factor authentication (MFA) is a security process that requires users to provide more than one way to verify their identity. This is more secure than just using a password (single-factor authentication). MFA usually combines something you know (like a password) and something you have (like a phone for a verification code).
How Multi-Factor Authentication (MFA) Works?
Step 1: Username and Password: You start by entering your username and password, just like you usually do to log into an account or system.
Step 2: Additional Verification: After you’ve entered your username and password, the system asks for an extra piece of information to confirm it’s really you. This extra step adds another layer of security.
Multi-Factor Authentication (MFA) works by requiring users to provide two or more independent credentials to verify their identity. This significantly enhances security because even if one factor (like a password) is compromised, an attacker still needs the additional factors to gain access.
By combining multiple forms of verification, MFA makes unauthorized access much more difficult. This means, even if an attacker gets your password, they would still need the second factor (like your phone) to access your account.
For this reason, two-factor authentication is demonstrably more secure than single-factor authentication.
Common Vulnerabilities in MFA
Multi-Factor Authentication (MFA) can still be vulnerable if not implemented properly. Poor configuration or weak design can allow attackers to bypass it. For example, using the same factor twice, like a password and a code sent to the same email, doesn’t significantly increase security. MFA can also be undermined by phishing attacks, where users are tricked into providing both their credentials and verification codes on fake websites. SIM swapping is another risk, where attackers gain control of a victim’s phone number to intercept verification codes. Additionally, man-in-the-middle (MITM) attacks can intercept and capture both authentication factors during transmission, rendering MFA ineffective in such scenarios.
Two-factor authentication tokens
Two-factor authentication (2FA) tokens add an extra layer of security when logging into a website. Users usually get a verification code from a physical device, like an RSA token or a keypad device, which generates the code directly. This is often used by high-security websites, such as online banking or work systems, because it’s very secure.
Another common method is using a mobile app, like Google Authenticator, which also generates verification codes directly on your phone.
However, some websites send these codes via SMS to your phone. This method is considered less secure. Since the code is sent over SMS, it can potentially be intercepted by attackers. There’s also the risk of SIM swapping, where an attacker tricks the phone company into giving them a SIM card with your phone number. If this happens, the attacker can receive all your SMS messages, including your 2FA codes.
Bypassing two-factor authentication
Sometimes, two-factor authentication (2FA) can have flaws that let attackers bypass it entirely. Here’s how it can happen:
Imagine you log into a website by first entering your password. After that, you’re asked to enter a verification code on a different page. The problem is, the website might treat you as “logged in” just after you enter your password, even before you enter the verification code.
This means you might be able to skip the verification step and directly access pages that should only be available after fully logging in. Essentially, the website doesn’t properly check if you completed the second step of the 2FA process before granting access to protected pages.
In such cases, an attacker could exploit this flaw to gain unauthorized access simply by entering the correct password and then going straight to “logged-in only” pages without entering the verification code.
Practical: 2FA simple bypass
Go to lab home page click “My account” to open login page.
Log in to given Username and Password that is (Your credentials: wiener:peter).
Now check the 2FA verification code will be sent to you by email. Click the Email client button to access your emails.
Log in by entering the verification code.
Go to your account page and make a note of the URL.
Log out of your account.
Log in using the victim’s credentials that is: carlos:montoya
When prompted for the verification code, manually change the URL to navigate to /my-account. The lab is solved when the page loads.
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:
Imagine a website where you need to log in using two steps for extra security.
Step 1: Normal Login
First, you enter your username and password:
POST /login-steps/first HTTP/1.1
Host: vulnerable-website.com
…
username=admin &password=s3cR3tp@$$If your login is successful, the website assigns a cookie that relates to your account:
HTTP/1.1 200 OK
Set-Cookie: account=adminStep 2: Two-Factor Verification
Next, you go to the second step where you need to enter a verification code:
GET /login-steps/second HTTP/1.1
Cookie: account=adminWhen you submit the verification code, it uses the cookie to identify your account:
POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=admin
…
verification-code=123456The Flaw and the Attack
Here’s the problem: The website doesn’t check if the person entering the verification code is the same person who logged in.
That means, an attacker can exploit this by logging in with their own credentials first:
POST /login-steps/first HTTP/1.1
Host: vulnerable-website.com
…
username=attacker&password=hackerpasswordThey get their own cookie:
HTTP/1.1 200 OK
Set-Cookie: account=attackerNow, they go to the second step. But instead of using their own cookie, they change it to the victim’s username:
POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=victim-user
…
verification-code=123456If the attacker can guess or brute-force the verification code, they can log in as the victim without needing the victim’s password.
Get SubhaDip’s stories in your inbox
Join Medium for free to get updates from this writer.
This flaw is extremely dangerous because it allows attackers to bypass the first authentication step entirely and focus on brute-forcing the verification code, potentially gaining unauthorized access to other users’ accounts.
Practical: 2FA broken logic
With Burp running, log in to your own account and investigate the 2FA verification process.
Notice that in the POST /login2 request, the verify parameter is used to determine which user's account is being accessed.
Log out of your account.
Send the GET /login2 request to Burp Repeater.
Change the value of the verify parameter to carlos and send the request. This ensures that a temporary 2FA code is generated for Carlos.
Go to the login page and enter your username and password. Then, submit an invalid 2FA code.
Send the POST /login2 request to Burp Intruder.
In Burp Intruder, set the verify parameter to carlos and add a payload position to the mfa-code parameter. Brute-force the verification code.
Go to payload section, select payload type: Brute Force and set character set only number from 0 to 9 and set min length: 4 and max length: 4. Then start the attack.
When the attack is finished, Notice that one of the status code is 302 than the others(200).
Right click on it then click on Show response in browser.
Copy the URL
Now, go to your browser, open new tab then paste the copied URL on it and hit enter and solve the lab.
Brute-forcing 2FA verification codes
Brute-forcing 2FA verification codes is a method attackers use to guess the code by trying many different combinations. These codes are usually short, like 4 or 6 digits, making them easier to crack without proper security measures.
Websites need to protect against brute-forcing because it can be easy for attackers to guess these simple codes. Some websites try to prevent this by logging a user out after several incorrect attempts. However, this method is often not effective. Advanced attackers can use automated tools, like creating macros or using tools like Burp Intruder and its Turbo Intruder extension, to quickly try many different codes even with the logout mechanism in place.
This means that without strong protections, brute-forcing 2FA codes can be a straightforward way for attackers to bypass this layer of security.
Practical: 2FA bypass using a brute-force attack
Make sure when you access the lab at first turn on the burp suite and also burp proxy to capture all request and response.
Then login with the given Username and Password that is: carlos:montoya
Enter dummy 4-digit security code two times and investigate the 2FA verification process. Notice that if you enter the wrong code twice, you will be logged out again.
To solve the lab, we need to use Burp’s session handling features to log back in automatically before sending each request.
In Burp Suite, go to Project options → Sessions. In the Session Handling Rules panel, click Add. The Session handling rule editor dialog opens.
In the dialog, go to the Scope tab. Under URL Scope, select the option Include all URLs.
Next, go back to the Details tab and under Rule Actions, click Add -> Run a macro.
Under Select macro click Add to open the Macro Recorder. Select the following 3 requests:
- GET /login
- POST /login
- GET /login2
Then click OK. The Macro Editor dialog opens.
Click Test macro and check that the final response status code. If the status code is 200, 302, 200, That meanes confirms that the macro is working correctly.
Keep clicking OK to close the various dialogs until you get back to the main Burp window. The macro will now automatically log you back in as Carlos before each request is sent by Burp Intruder.
Open Proxy tab -> HTTP History. Then find the POST /login2 Request (Enter a Random 2FA Code) and send it to the Intruder.
In Burp Intruder, add a payload position to the mfa-code parameter.
On the Payloads tab, select the Numbers payload type. Enter the range 0–9999 and set the step to 1. Set the min/max integer digits to 4 and max fraction digits to 0. This will create a payload for every possible 4-digit integer.
Go to the Resource pool tab and add the attack to a resource pool with the Maximum concurrent requests set to 1.
Start the attack. Eventually, one of the requests will return a 302-status code.
Select this request. Then Right-click on this request and select Show response in browser. Copy the URL and load it in the browser.
Paste the URL into the new tab -> click on My account to solve the lab.
I hope you enjoyed this write-up! Thank You! Happy Hacking :)
Follow to me on Medium and be sure to turn on email notifications so you never miss out on my latest informative posts.
Follow me on below Social Media:
- LinkedIn: Subhadip Sardar
- Twitter | X : @Mr_SubhaDip03
- GitHub : SubhaDip003
- Check My TryHackMe Profile : TryHackMe | SubhaDip
