Delving into Offensive Pentesting Strategies and Advanced 2FA Bypass Techniques

In the realm of penetration testing, where the objective is to identify and exploit vulnerabilities before malicious actors do, authorization and authentication mechanisms stand as critical gatekeepers. Understanding the weaknesses within these security layers is paramount for fortifying digital defenses. In this article, we explore the nuances of authorization and authentication failures, shedding light on potential vulnerabilities and effective testing methodologies. Here, I am explaining some unique strategies from personal research and my previous experience.

## Exposed Session Identifiers: URL-based Session Management:

One common vulnerability that often arises is the exposure of session identifiers in the URL, a flaw that can significantly compromise session security. This vulnerability occurs when session tokens or identifiers are appended to URLs as parameters, making them susceptible to interception and exploitation. For instance, during a pentest, if a session identifier is exposed in the URL, it can be intercepted by an attacker through various means, such as network sniffing or malicious browser extensions. Once intercepted, the attacker can hijack the session and gain unauthorized access to the user's account or sensitive information. To illustrate, consider the following raw HTTP GET request:

In this example, the session identifier "abc123" is appended to the URL as a parameter, making it visible and vulnerable to interception. Pentesters often simulate such scenarios to demonstrate the risks associated with session identifier exposure and advocate for secure session management practices, such as using HTTP cookies with secure attributes to store session identifiers instead of exposing them in the URL.

## Exploring Privilege Escalation through Parameter Manipulation in User Sign-Up Processes:

Manipulating parameters during user sign-up processes is a common technique used to escalate privileges or reveal hidden functionalities. One example of such manipulation is adding a parameter like "is_admin=true" during the sign-up request, aiming to acquire administrative privileges. For illustration, examine the following raw HTTP POST requests:

Sign-up Request 1

Sign-up Request 2 (Exploited)

In the second request, the attacker manipulates the "is_admin" parameter to "true," thereby granting themselves administrative privileges upon sign-up. Pentesters leverage such techniques not only to escalate privileges but also to uncover hidden functionalities within user management panels. By fuzzing parameters and meticulously analyzing responses, pentesters identify hidden parameters or functionalities that could be exploited for unauthorized access or privilege escalation. This underscores the importance of thorough parameter validation and access control mechanisms during application development to mitigate the risk of parameter manipulation attacks.

You can also use 'admin,' 'administrator,' '1,' 'god,' or any other highly privileged user role if the application supports it or if they have any role like these in the sign-up request.

## Password Reset Token and OTP Generation Algorithms in JavaScript Files:

Understanding the inner workings of password reset token and one-time password (OTP) generation algorithms is crucial for identifying potential vulnerabilities within web applications. A common approach employed by pentesters involves scrutinizing JavaScript files, where developers often document or implement such algorithms. By dissecting these files, pentesters gain insights into the underlying mechanisms used to generate reset tokens or OTPs, enabling them to uncover weaknesses that could be exploited by malicious actors. Here, we delve into the intricacies of OTP and password reset token generation by presenting three distinct JavaScript code snippets that illustrate different approaches to achieving this:

Example 1: Simple OTP Generation

This straightforward function generates a six-digit OTP by randomly selecting digits from the '0123456789' string.

Example 2: Password Reset Token Generation

Here, a password reset token consisting of alphanumeric characters is generated. The function iterates 16 times, appending a randomly selected character from the 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789' string to the token each time.

Example 3: Enhanced OTP Generation with Alphanumeric Characters

In this example, an enhanced OTP comprising eight alphanumeric characters is generated. The function selects characters from the 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789' string, adding an additional layer of complexity to the OTP generation process.

By analyzing JavaScript files containing such code snippets, pentesters gain valuable insights into the methods employed by web applications to generate reset tokens and OTPs. This understanding facilitates the identification of potential weaknesses or vulnerabilities in the token generation process.

## Bypassing Authorization via HTTP Methods: 

It's not uncommon to encounter scenarios where certain HTTP methods might bypass authorization checks. This can be exploited to gain unauthorized access to restricted resources. By testing various HTTP methods, pentesters can identify and leverage such weaknesses to bypass security controls. Here is an illustrative example showing how a seemingly restricted endpoint can be accessed using different HTTP methods:

Example Scenario: Authorization Bypass Using HTTP Methods

During a pentest, you encounter a restricted endpoint that denies access when using a standard GET request. However, by switching to an OPTIONS request, the same endpoint responds successfully, indicating a potential authorization bypass.

GET Request (Authorization Failure)

OPTIONS Request (Authorization Success)

Response

In this example, the GET request to the /instructor/performance/students/?course_id=497558 endpoint returns a 403 Forbidden response, indicating that access is denied. However, when the same endpoint is accessed using an OPTIONS request, it returns a 200 OK response, listing the allowed methods and suggesting that the server does not enforce the same authorization checks for OPTIONS requests.

## Identifying Cache Poisoning Vulnerabilities Through User Access Patterns:

Exploring access patterns across different user roles can uncover vulnerabilities like cache poisoning. By comparing responses to requests made by different user accounts, pentesters can pinpoint potential security weaknesses. Here's how to conduct such tests with two example scenarios:

Example Scenario: Admin Account Access

Then try to browse the same endpoint with the user account. Observe the response status code, which may be different from the admin account.

To further investigate, appending ‘.json’ to the URL (/admin/settings.json) from the admin account and showing the same page, may reveal cache poisoning vulnerabilities. If the ‘.json’ request returns a 200 status code, it indicates that the server caches responses based on URL extensions, potentially exposing sensitive data to unauthorized users.

## Exploiting Vulnerabilities in Base64 Encoded Password Reset Tokens:

Encountering base64-encoded password reset tokens during offensive pentesting can unveil critical vulnerabilities in an application's security. By manipulating these tokens, attackers might bypass authorization controls, allowing them to misuse tokens for unauthorized access. Consider the following scenario:

Exploiting Base64 Encoded Password Reset Tokens:

Upon intercepting a base64-encoded password reset token (e.g., 511WlvSGdzNWZrTTVJUmZHcmAvUOxab3I4RlBJPQ=), pentesters can attempt to exploit vulnerabilities by manipulating the token's encoding.

Base64 encoding is commonly used to transmit binary data as ASCII text, and padding with equals signs ('=') is utilized to ensure that the encoded string's length is a multiple of 4 bytes. However, altering the padding can sometimes lead to bypassing token authorization checks, enabling attackers to reuse tokens multiple times for unauthorized access.

## Checking for Referrer Policy on Reset Password Pages:

One critical check is to ensure that the reset password page includes a Referrer Policy tag set to "noreferrer." This is crucial because the absence of this policy can lead to referrer leakage, where sensitive information in the URL, such as tokens or email addresses, could be inadvertently exposed to external sites. Such leakage can be exploited by attackers for account takeover. Here’s an example to illustrate:

Example: Inspecting the Reset Password Page

While examining the reset password functionality, you could come across the following HTML structure:

What to Look For: Presence of Referrer Policy Tag: Verify if the <meta name="referrer" content="no-referrer"> tag is included in the HTML head. This tag ensures that the referrer information is not sent when users navigate away from the reset password page.

Advanced 2FA Bypass Techniques

Multi-factor authentication (MFA) and two-factor authentication (2FA) stand as bulwarks against unauthorized access. However, their vulnerabilities exist, inviting exploration and discovery. This part of the article delves into the intricacies of bypassing 2FA/MFA mechanisms, uncovering unique techniques that transcend conventional defenses.

## Vulnerable Login Panels Across Subdomains:

Searching for vulnerabilities in two-factor authentication (2FA) systems by scrutinizing an organization's subdomains. For instance, suppose testers discover a subdomain, 'admin.example.com,' hosting a login panel that lacks OTP enforcement and occasionally redirects or creates a combined session for all subdomains. For example, https://mbasic.facebook.com  and https://facebook.com.

## Manipulating conditions within the authentication request to potentially bypass security controls:

For instance, testers may alter parameters such as "mode" from "sms" to "email" and "secureLogin" from true to false during the login process or within the response to username and password inputs. By making these modifications, testers aim to exploit weaknesses in the 2FA implementation, potentially circumventing the additional security layer intended to protect user accounts. Let's consider an example request:

Original Request:

‍

Modified Request

In this modified request, parameters such as "mode" and "secureLogin" have been altered, potentially affecting the authentication flow and introducing vulnerabilities. This technique underscores the importance of thorough testing and highlights the need for strong authentication mechanisms to defend against exploitation attempts.

## Exploiting OTP Sending Requests:

Another potent technique in bypassing two-factor authentication (2FA) involves manipulating OTP sending requests to impersonate users and bypass 2FA checks. After successfully logging in, attackers intercept the request responsible for sending OTP codes. Within this request, there's often a parameter identifying the user's unique identifier (UID). Attackers then modify this request, substituting the victim's UID with their own and providing their own OTP code. This manipulation tricks the system into validating the attacker's OTP instead of the legitimate user's, effectively bypassing 2FA. Below illustrates the attack scenario:

Original OTP Sending Request

Modified OTP Sending Request

In this altered request, the attacker replaces the victim's UID with their own and provides their own OTP code. This deceitful request fools the system into accepting the attacker's OTP, granting unauthorized access without the need for the legitimate user's approval. 

## Exploiting Password Reset Mechanisms to Bypass 2FA and Authentication Factors:

A unique tactic involves exploiting password reset mechanisms to circumvent two-factor authentication (2FA) and reset additional authentication factors, facilitating unauthorized access to web applications. This technique unfolds in several steps: first, attackers request a password reset token through the application's password reset functionality. Upon receiving the token, they proceed to utilize it to reset the password associated with the targeted user account. Following this, attackers change the password to one they control. With the updated password, attackers can then effortlessly log in to the web application without encountering the 2FA requirement, effectively sidestepping the supplementary layer of security. Moreover, in certain scenarios, attackers may discover that the password reset process also resets other authentication factors, further streamlining the path to unauthorized access. This tactic underscores the critical importance of bolstering authentication mechanisms and prompts organizations to implement comprehensive security controls to mitigate the risk of such exploits.

## Exploiting Vulnerable Activation Links for Persistent Access:

One method of unauthorized access involves exploiting activation links that lack token expiration, thereby allowing attackers to continuously use them for login. Some applications employ magic links or URLs provided during signup for authentication. Attackers exploit this vulnerability by attempting login using these activation links even after enabling OTP. Furthermore, attackers can abuse another feature where activation links are used for signup. Upon activation, attackers can try to login using the same link, gaining unauthorized access. An example scenario illustrates this process:

Example

By exploiting these vulnerable activation links, attackers gain persistent access to the application, highlighting the critical need for token expiration and validation mechanisms.

## Exploiting Post-2FA Redirection:

After successfully entering a valid 2FA code during login, attackers analyze the subsequent redirection location. They then attempt to directly navigate to this URL using their victim's account, bypassing the 2FA requirement. This exploit takes advantage of insecure redirection flows, enabling attackers to circumvent additional security measures. An example illustrates this process:

1. Attacker logs in with the victim's credentials and successfully enters a valid 2FA code.
2. Upon successful authentication, the application redirects to a specific URL, such as: https://example.com/dashboard

Attacker attempts to access this URL directly using the victim's account after providing the password, bypassing 2FA:

By exploiting post-2FA redirection vulnerabilities, attackers gain unauthorized access to sensitive areas of the application, highlighting the critical need for robust access control mechanisms and secure redirection handling.

## Analyzing OTP Request Responses for Potential 2FA Code Leakage:

A critical technique in bypassing two-factor authentication (2FA) involves scrutinizing the server's response to OTP requests for any signs of code leakage or encoded strings that may contain the OTP. Attackers analyze the response to determine if the OTP is inadvertently disclosed or if there are any hints within encoded data that can be decoded to reveal the OTP. This method involves a careful examination of the server's responses during the authentication process. Here's how it can be done:

Request OTP

Analyze Server Response

In this example, the server's response includes an encoded_data field. Attackers decode this base64-encoded string:

Decoded String

By decoding the string, attackers can extract the OTP code (123456). This vulnerability highlights the importance of ensuring that sensitive information like OTP codes is not leaked in any form within server responses.

## Analyzing JavaScript Files for Information to Bypass 2FA Code:

Analyzing JavaScript (JS) files that are referenced in the server's response during the 2FA code request process. Attackers can inspect these JS files to uncover information or vulnerabilities that might aid in bypassing the 2FA mechanism. This method requires a detailed examination of the scripts to find any hardcoded values, functions, or logic that could be exploited. Here’s how this can be approached:

Trigger the 2FA Code Request:

Analyze the Server Response and Referenced JS Files

main.js

This function, 'generateOTP', generates a six-digit random OTP by adding a random number between 0 and 900,000 to 100,000 and then flooring the result. The generated OTP is returned as the function's output.

auth.js

In this example, the JavaScript file auth.js contains a function sendOTP that uses a secretKey and generates an OTP. The function logs the OTP to the console, which could be a significant vulnerability if the OTP is exposed in any way during the execution.

‍## Manipulating the Request by Removing 2FA Parameter

A common technique in offensive security testing involves attempting to bypass two-factor authentication (2FA) by removing or tampering with the 2FA parameters in requests. This method can sometimes trick the server into granting access without requiring the second factor of authentication, particularly if the backend does not properly enforce 2FA at every stage of the authentication process. Instead of submitting the 2FA code, an attacker can attempt to bypass the 2FA step by manipulating the request to exclude 2FA parameters, potentially exploiting backend vulnerabilities or misconfigurations. Here’s how this technique can be executed:

Manipulated Login Request (Removing 2FA Parameters) from the second request:

Possible Outcomes

Success: If the server does not correctly enforce 2FA, it might grant access based on the initial login credentials alone, allowing the attacker to bypass the 2FA requirement.

Failure: If the server is properly configured, it will reject the request due to missing 2FA parameters, thus maintaining the security integrity of the authentication process.

‍