5 Common Methods to Bypass OTP Authentication in Bug Hunting

An authentication bypass vulnerability is a weakness in a system that’s supposed to check who a user is. It allows attackers to slip past these security measures and gain unauthorized access to systems.

Imagine a supposed high-security building with a fancy fingerprint scanner at the entrance. An authentication bypass vulnerability would be like a secret backdoor someone could use to get in without needing a fingerprint.

1. Response Manipulation

Sometimes the server doesn’t check the input given on the client side or is modified in between and takes decisions, leading to the respective vulnerability.

Also, making decisions only based on boolean values or a number leads to this vulnerability.

Methodology:

• The Standard Login Process: A user submits their username and password during login. The application validates these credentials with the server and sends a response indicating success or failure.
• The manipulation: The attacker intercepts the communication between the user and the server. This can be done using tools like Burp Suite. They then modify the server’s response before it reaches the user’s browser.
• Bypassing Authentication: The attacker specifically targets the part of the response that determines if the login was successful. They might change a value from “false” (login failed) to “true” (login successful).

An example to help you understand it better:

• An insecure OTP verification system: Imagine a website uses a one-time password (OTP) for login after an initial username is provided. The website sends the OTP to the user’s phone and verifies the submitted code.
• The Vulnerability: The system might have a flaw where the server’s response to the OTP verification simply says “true” or “false” depending on if the code matches.
• The Attack: An attacker intercepts the user’s request after they submit an incorrect OTP. They modify the server’s response from “false” to "true.”. The user’s browser receives this manipulated response and displays a successful login message, even though the real OTP was wrong.

2. MFA Code Leakage in response

Multi-factor authentication (MFA) code leakage in response authentication bypass is a sneaky tactic attackers use to circumvent the additional security layer provided by MFA.

Sometimes different applications reveal the verification code, or OTP, in the response itself, leading to various attacks by an attacker.

Methodology:

• The MFA Process: Normally, after entering a username and password, a valid MFA code (one-time password, SMS code, etc.) is required for final verification. The application sends a request to the server to validate the submitted MFA code.
• Vulnerability: The issue arises when the server’s response to the MFA code validation isn’t properly secured. Instead of just indicating success or failure, the response might inadvertently leak the actual valid MFA code itself.
• Exploiting the Leak: An attacker intercepts the communication between the user and the server. They see the server’s response containing the valid MFA code.
• Bypassing Authentication: With the stolen MFA code, the attacker can now bypass the MFA step and potentially gain access to the account, even if they don’t know the user’s password.

An example to help you understand it better:

• A vulnerable banking application: Imagine a banking app that uses SMS verification for MFA. When a user enters the correct login credentials and the SMS code, the server validates the code and grants access.
• The flaw: Let’s say the server’s response to MFA code verification includes the actual code itself along with a success message.
• The Attack: An attacker intercepts the user’s request after they submit a valid MFA code. They see the server’s response containing the code. Now, the attacker can use this stolen code to bypass MFA for their login attempt and potentially access the victim’s bank account.

3. Brute Force MFA Code

Sometimes applications do not limit the request from the client side on particular endpoints and the absence of proper rate limiting leads to brute forcing the MFA code which further leads to malicious attacks.

Brute-forcing MFA codes for authentication bypass are generally not as effective as with traditional passwords due to the inherent nature of MFA codes.

Limited Effectiveness:

• Shortcodes: MFA codes are typically shorter than passwords, making them less susceptible to brute-forcing attempts. For instance, a 6-digit code offers significantly fewer possibilities compared to an 8-character password.
• Time constraints: Many MFA codes are time-based or have limited attempts. This restricts the number of guesses an attacker can make within a valid window.
• Rate limiting: Secure systems often implement rate limiting on MFA code attempts. This thwarts brute-force attacks by throttling the number of attempts allowed in a specific time frame.

Methodology:

• Weak MFA codes: The system uses 4-digit numeric codes with no time constraints or rate limiting.
• Login attempt limit: There’s only a limit on the number of username/password attempts (say, 5 attempts).

An example to help you understand it better:

1. An attacker obtains the username and password for a target account (through phishing or other means).
2. They exploit the lack of limitations on MFA attempts.
3. The attacker uses a script or automated tool to try a large number of 4-digit code combinations (0000 to 9999).

Sensitive Information within JS files and GitHub

Sometimes developers hide hard-coded credentials, secret endpoints, or unauthenticated admin panel links in “javascript files.”. Sometimes, developer’s or company GitHub repositories containing sensitive information regarding their site remain public.

Example: API keys, passwords, auth- tokens, insecure admin- panels, etc. in GitHub repos or in JS files.

You can use this tool to discover JS files: JSFScan GitHub

4. Sensitive Information Leakage in JS Files:

Methodology:

• The Problem: JavaScript (JS) files are essential for adding interactivity to web pages. However, if sensitive information like API keys, passwords, or access tokens is inadvertently stored within these files, it can be exposed to anyone viewing the source code.
• The Impact: Attackers who gain access to this sensitive information can exploit it for various malicious purposes. They could steal data, hijack accounts, or disrupt website functionality.

Example to understand it better:

Imagine a website stores its API key for a payment gateway directly in a JS file. An attacker who manages to inspect the source code can steal this key and potentially use it to process fraudulent transactions.

GitHub Authentication Bypass:

Methodology:

• The Potential Vulnerability: GitHub is a popular platform for hosting code repositories. It offers various authentication methods to control access to repositories. An authentication bypass vulnerability would be a weakness that allows unauthorized users to gain access to a repository even without valid credentials.
• Broken Authentication Mechanism: Imagine a hypothetical flaw in GitHub’s authentication process that allows an attacker to manipulate a request in a specific way to bypass login.
• Exploiting Weaknesses (Hypothetical): While GitHub implements strong security measures, let’s explore a hypothetical scenario to understand the concept:

5. Authentication bypass via Host-Header injection

Host-header injection is a vulnerability that attackers can exploit to gain unauthorized access to a system by manipulating the “Host” header in an HTTP request.

Some web applications have a security flaw where they rely on the host header for access control decisions. Imagine an e-commerce website with an “admin panel” accessible only to authorized staff. The application might mistakenly check the host header to determine if a user is allowed to see the panel.

Methodology:

1. Target Website: An e-commerce website with an admin panel accessible only for requests coming from the internal domain “[invalid URL removed]” ([invalid URL removed]).
2. Attacker’s Action: The attacker uses a tool like Burp Suite to intercept a normal request to the website.
3. Modifying the Request: They modify the intercepted request and change the host header to “[invalid URL removed]” (pretending to be from the trusted internal network).
4. Resending the Request: The attacker resends the manipulated request to the web server.

Example to understand it better:

Imagine a fictional e-commerce website called “ShopItAll” with an admin panel accessible only to authorized staff. Here’s how an attacker might exploit a host-header vulnerability to gain unauthorized access:

1. Vulnerability Discovery: The attacker discovers that ShopItAll’s login process relies on the host header to determine user permissions. Normally, legitimate users access the site through the public domain “[invalid URL removed]”. However, the attacker finds that the system mistakenly grants access to the admin panel if the request comes from a specific internal domain, like “[invalid URL removed]”.
2. Exploiting the Flaw: The attacker uses a tool like Burp Suite to intercept a normal login request to ShopItAll. They modify the request by changing the host header from “[invalid URL removed]” to “[invalid URL removed]”. This essentially tricks the server into thinking the request originates from the trusted internal domain.
3. Bypassing Authentication: The attacker resends the manipulated login request with the modified host header. If ShopItAll is vulnerable to host-header injection, the server might misinterpret the request and grant access to the admin panel, even though the attacker doesn’t have the correct admin credentials.