I saw a post a while ago where some people on the forum were looking for useful 2FA bypass methods. I wanted to write something detailed about it. Here I will talk about some 2FA bypass methods that I have found and used before.
Method 1
1. First Step (Login):
The user sends a POST request to log in with the traditional username and password.
The server authenticates the user with credentials and creates a cookie.
2. Second Step (Send Verification Code):
The user goes to the second verification step and calls the verification page with a GET request. In this request, the cookie created in the previous step is also sent to the server.
The server sends the user a form to enter a verification code.
3. Sending the Verification Code:
The user sends a POST request by entering the verification code and preserving the cookie received in the previous step.
The server checks the verification code and verifies the account specified in the cookie.
As a result of these steps, the attacker can log in with their own credentials in the first step and then access the target user's account using the target user's cookie when sending the verification code. This is a vulnerability caused by not validating the cookie value securely enough.
Method 2 - lickjacking on 2FA Disable Feature:
1. Attempt to Iframe the page where the application allows a user to disable 2FA.
In this step, the attacker tries to embed the page containing the option to disable two-factor authentication (2FA) within an iframe. This allows the attacker to display the content of the target page on their own malicious website.
This iframe will appear on a webpage under the control of the attacker.
2. If Iframe is successful, try to perform a social engineering attack to manipulate the victim to fall into your trap.
In this step, the attacker uses social engineering techniques to deceive the user. This may involve manipulation and deceptive tactics to persuade the user to click on or interact with the iframe content.
Example of a social engineering scenario:
- The attacker reaches out to the user via email or social media message and provides a reason for the user to visit the page where 2FA can be disabled. For example, "To make your account more accessible, you need to disable 2FA."
- The attacker may mimic the logo, design, or URL of the target website to provide a convincing appearance of trustworthiness.
- The user sees the deceptive message or email and, believing the content, clicks on or interacts with the 2FA disable page within the iframe.
- The user falls into the trap, thinking they are disabling their own 2FA settings.
This attack can lead to the disabling of 2FA by tricking users into clicking on or interacting with content they believe comes from a trustworthy source. Therefore, appropriate measures should be taken to prevent Clickjacking in web applications, and users should be educated against social engineering tactics.
Method 3 - Response Manipulation:
Sure, let's translate it into English:
1. Checking the Response of the 2FA Request:
First, the attacker uses an HTTP proxy tool to capture and inspect the response of the two-factor authentication (2FA) request sent by the user. This tool allows intercepting the request and examining the response from the server. Tools like Burp Suite can be used for this purpose.
An example of such a request could be:
An example response could be:
2. If "Success": false is Observed:
If the response contains "Success": false, it indicates that the 2FA was not successful. This information can be obtained by checking the "Success" header, especially if the response is in JSON format.
3. Change this Value to "Success": true and See if it Bypasses the 2FA:
The attacker modifies the response to change the value of the "Success" parameter from false to true. This modification can be done using the response editing feature of the HTTP proxy tool.
After modifying the response, the attacker resends the request to the server. The headers of the request should carry the original headers to avoid detection.
If the server does not perform additional verification or validation, it may consider the modified response as indicating successful 2FA. In such cases, the attacker can bypass the 2FA and gain unauthorized access to the target account.
This method relies on manipulating HTTP requests and responses to trick the server into believing that 2FA was successful. However, it only works if the server trusts client-provided data for authentication without performing sufficient validation. To enhance security, servers should validate incoming data from untrusted sources and implement additional verification steps if necessary.
Method 4 - Status Code Manipulation:
Of course, let's translate it into English:
1. Checking the Response Status Code:
Firstly, the attacker intercepts the response of the response of the two-factor authentication (2FA) request and examines the HTTP status code in the response. The status code indicates the processing status of the request. For instance, the 401 (Unauthorized) code signifies that the request is not authorized, indicating a potential issue with the 2FA authentication process.
2. Changing the Response Status Code to "200 OK" and Testing Bypass:
The attacker modifies the intercepted response by changing the original 4xx error code to "200 OK." This implies that the server successfully processed the request and it was completed without any errors. Before sending the modified response, the HTTP headers and content need to be properly adjusted.
Here's an example of modifying the response status line:
Original Response:
Modified Response:
The modified response is then sent to the server. If the server does not implement additional verification steps or fails to authenticate the request, the attacker may successfully bypass the 2FA authentication.
Method 5 - 2FA Code Reusability:
Certainly, here's the explanation in English:
1. 2FA Code Reusability:
Firstly, the user requests a 2FA code and uses it for authentication. This typically involves receiving a verification code via SMS, email, or an authenticator app and entering it during the login process.
2. Reuse of the Same 2FA Code:
The attacker attempts to reuse a previously used 2FA code. If the code is successfully reused, it indicates a security issue because 2FA codes should be single-use only.
3. Requesting Multiple 2FA Codes and Code Expiry:
The attacker requests multiple 2FA codes to check if previously requested codes are still valid. If the previous codes remain valid and do not expire when a new code is requested, it indicates a security vulnerability. Each code should have a limited validity period and should expire after use.
4. Long-Term Reusability of 2FA Codes:
The attacker tries to reuse a previously used 2FA code after a long period, such as 1 day or more. If the old code is still valid and successfully used, it indicates a security flaw. 2FA codes should be designed to be difficult to guess or crack within a short period, and they should not remain valid for an extended period.
Method 6 - Direct Redirection:
Sure, here are the English translations for the provided examples:
1. Direct Redirection to 2FA Page After Successful Authentication:
In this step, the attacker needs to direct the browser to a specific URL. The browser sends this request carrying normal HTTP headers.
Sample HTTP request:
2. Changing the Referer Header to the 2FA Page URL:
In this step, the attacker needs to change the Referer header to the URL of the desired page. The Referer header typically indicates from which previous page a HTTP request originated.
Sample HTTP request:
In general, I told you about the methods I used (in this part, I did not include things that no longer work, such as null bytes.) If you like it, put like, if you have any questions, I will answer them.
pele wishes you all good hacks
Method 1
1. First Step (Login):
The user sends a POST request to log in with the traditional username and password.
HTML:
POST /login-steps/first HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
username=carlos&password=qwertyThe server authenticates the user with credentials and creates a cookie.
HTML:
HTTP/1.1 200 OK
Set-Cookie: account=carlos2. Second Step (Send Verification Code):
The user goes to the second verification step and calls the verification page with a GET request. In this request, the cookie created in the previous step is also sent to the server.
HTML:
GET /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=carlosThe server sends the user a form to enter a verification code.
HTML:
HTTP/1.1 200 OK
Content-Type: text/html
<form action="/login-steps/second" method="post">
<label for="verification-code">Verification Code:</label>
<input type="text" id="verification-code" name="verification-code">
<input type="submit" value="Submit">
</form>3. Sending the Verification Code:
The user sends a POST request by entering the verification code and preserving the cookie received in the previous step.
HTML:
POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=carlos
Content-Type: application/x-www-form-urlencoded
verification-code=123456The server checks the verification code and verifies the account specified in the cookie.
As a result of these steps, the attacker can log in with their own credentials in the first step and then access the target user's account using the target user's cookie when sending the verification code. This is a vulnerability caused by not validating the cookie value securely enough.
Method 2 - lickjacking on 2FA Disable Feature:
1. Attempt to Iframe the page where the application allows a user to disable 2FA.
In this step, the attacker tries to embed the page containing the option to disable two-factor authentication (2FA) within an iframe. This allows the attacker to display the content of the target page on their own malicious website.
HTML:
<iframe src="https://vulnerable-website.com/disable-2fa"></iframe>This iframe will appear on a webpage under the control of the attacker.
2. If Iframe is successful, try to perform a social engineering attack to manipulate the victim to fall into your trap.
In this step, the attacker uses social engineering techniques to deceive the user. This may involve manipulation and deceptive tactics to persuade the user to click on or interact with the iframe content.
Example of a social engineering scenario:
- The attacker reaches out to the user via email or social media message and provides a reason for the user to visit the page where 2FA can be disabled. For example, "To make your account more accessible, you need to disable 2FA."
- The attacker may mimic the logo, design, or URL of the target website to provide a convincing appearance of trustworthiness.
- The user sees the deceptive message or email and, believing the content, clicks on or interacts with the 2FA disable page within the iframe.
- The user falls into the trap, thinking they are disabling their own 2FA settings.
This attack can lead to the disabling of 2FA by tricking users into clicking on or interacting with content they believe comes from a trustworthy source. Therefore, appropriate measures should be taken to prevent Clickjacking in web applications, and users should be educated against social engineering tactics.
Method 3 - Response Manipulation:
Sure, let's translate it into English:
1. Checking the Response of the 2FA Request:
First, the attacker uses an HTTP proxy tool to capture and inspect the response of the two-factor authentication (2FA) request sent by the user. This tool allows intercepting the request and examining the response from the server. Tools like Burp Suite can be used for this purpose.
An example of such a request could be:
HTML:
POST /2fa-verify HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 36
{"code":"123456","user_id":"123"}An example response could be:
HTML:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 38
{"success":false, "message": "Invalid code"}2. If "Success": false is Observed:
If the response contains "Success": false, it indicates that the 2FA was not successful. This information can be obtained by checking the "Success" header, especially if the response is in JSON format.
3. Change this Value to "Success": true and See if it Bypasses the 2FA:
The attacker modifies the response to change the value of the "Success" parameter from false to true. This modification can be done using the response editing feature of the HTTP proxy tool.
After modifying the response, the attacker resends the request to the server. The headers of the request should carry the original headers to avoid detection.
If the server does not perform additional verification or validation, it may consider the modified response as indicating successful 2FA. In such cases, the attacker can bypass the 2FA and gain unauthorized access to the target account.
This method relies on manipulating HTTP requests and responses to trick the server into believing that 2FA was successful. However, it only works if the server trusts client-provided data for authentication without performing sufficient validation. To enhance security, servers should validate incoming data from untrusted sources and implement additional verification steps if necessary.
Method 4 - Status Code Manipulation:
Of course, let's translate it into English:
1. Checking the Response Status Code:
Firstly, the attacker intercepts the response of the response of the two-factor authentication (2FA) request and examines the HTTP status code in the response. The status code indicates the processing status of the request. For instance, the 401 (Unauthorized) code signifies that the request is not authorized, indicating a potential issue with the 2FA authentication process.
2. Changing the Response Status Code to "200 OK" and Testing Bypass:
The attacker modifies the intercepted response by changing the original 4xx error code to "200 OK." This implies that the server successfully processed the request and it was completed without any errors. Before sending the modified response, the HTTP headers and content need to be properly adjusted.
Here's an example of modifying the response status line:
Original Response:
HTML:
HTTP/1.1 401 Unauthorized
Content-Type: application/json
Content-Length: 38
{"error": "Invalid authentication, "success": false}Modified Response:
HTML:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 45
{"success": true, "message": "OK"}The modified response is then sent to the server. If the server does not implement additional verification steps or fails to authenticate the request, the attacker may successfully bypass the 2FA authentication.
Method 5 - 2FA Code Reusability:
Certainly, here's the explanation in English:
1. 2FA Code Reusability:
Firstly, the user requests a 2FA code and uses it for authentication. This typically involves receiving a verification code via SMS, email, or an authenticator app and entering it during the login process.
2. Reuse of the Same 2FA Code:
The attacker attempts to reuse a previously used 2FA code. If the code is successfully reused, it indicates a security issue because 2FA codes should be single-use only.
3. Requesting Multiple 2FA Codes and Code Expiry:
The attacker requests multiple 2FA codes to check if previously requested codes are still valid. If the previous codes remain valid and do not expire when a new code is requested, it indicates a security vulnerability. Each code should have a limited validity period and should expire after use.
4. Long-Term Reusability of 2FA Codes:
The attacker tries to reuse a previously used 2FA code after a long period, such as 1 day or more. If the old code is still valid and successfully used, it indicates a security flaw. 2FA codes should be designed to be difficult to guess or crack within a short period, and they should not remain valid for an extended period.
Method 6 - Direct Redirection:
Sure, here are the English translations for the provided examples:
1. Direct Redirection to 2FA Page After Successful Authentication:
In this step, the attacker needs to direct the browser to a specific URL. The browser sends this request carrying normal HTTP headers.
Sample HTTP request:
Код:
GET /authenticated_page HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Language: en-US,en;q=0.92. Changing the Referer Header to the 2FA Page URL:
In this step, the attacker needs to change the Referer header to the URL of the desired page. The Referer header typically indicates from which previous page a HTTP request originated.
Sample HTTP request:
Код:
GET /authenticated_page HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Language: en-US,en;q=0.9
Referer: https://example.com/2fa_pageIn general, I told you about the methods I used (in this part, I did not include things that no longer work, such as null bytes.) If you like it, put like, if you have any questions, I will answer them.
pele wishes you all good hacks
Последнее редактирование модератором:
