MFA

Broken Multi-Factor Authentication (MFA) logic occurs when an attacker can bypass or exploit weaknesses in the MFA implementation, allowing unauthorized access despite the presence of additional authentication factors.

This can lead to unauthorized account access, as attackers may exploit flaws to bypass MFA protections and gain access to sensitive information or systems.

Ensure MFA is properly integrated and enforced, use strong and diverse authentication factors, regularly review and update MFA mechanisms, and monitor for suspicious activities or bypass attempts.

Simple 2FA Bypass

The example below is based on PostSwigger's 2FA simple bypass lab.

We first need to login in as a normal user and understand how the 2FA process works (Figure 1).

Figure 1: Using the application as intended and understanding its behaviour.

We can also inspect what's happening behind the scene during this 2FA process (Figure 2).

Figure 2: Intercepting the traffic associated with the 2FA process.

It seems that each authentication step issues a different session cookie (Figure 2). There is a chance that we can use either of the two cookies to access the user's account. If this is the case, it means that the second authentication step is redundant and can be skipped altogether. We can test this by logging in as carlos, intercept the traffic, get the first session cookie, and then use it to access his account (Figure 3).

Figure 3: Bypassing the second authentication step & accessing carlos's account.

Broken 2FA logic

The example below is based on PostSwigger's 2FA broken logic lab.

As before, the first thing we need to do, is to try and understand how the authentication process works (Figure 4 & 5).

Figure 4: Logging in as wiener and inspecting how the first part of the authentication process works.

Figure 5: Logging in as wiener and inspecting how the second part of the authentication process works.

We can tamper with the cookie generated in the second step of the authentication process, and create a valid session cookie tied in the account carlos (Figure 6).

Figure 6: Creating a valid session cookie tied to carlos.

Next, we can use this cookie to brute-force carlos's mfa-code (Figure 7) and impersonate the user (Figure 8).

Figure 7: Brute-forcing carlos's 4-digit code.

The session cookie differs between Figure 7 & Figure 8 due to a lab reset.

Figure 8: Impersonating user carlos.

Broken 2FA logic (2)

The example below is based on TCM's Practical Bug Bounty course.

We should first go through the MFA process to understand how it works. We first login it with valid credentials (Figure 8.1), we then get a link to grab our code (Figure 8.2), and finally we enter our username and mfa code to log into the application (Figure 8.3).

Figure 8: The web application's MFA process.

The last step of the MFA process is extremely weak as it only asks for our username and a predictable six-digit code. Thus, we can try and perform a BFA to the mfa code as jeremy. Unfortunately, the application breaks after a while, so we will need to find another solution.

We can check if the mfa code is tied to a specific user by logging in as jessamy (Figure 9.1) and modifying the username of the second authentication step to jeremy (Figure 9.3).

Figure 10: Bypassing the MFA process.