daemon-sec-cheatsheet

The cheatsheet vault for operators: AD, enumeration, exploitation, priv-esc, web, DFIR
git clone https://git.daemon-sec.xyz/daemon-sec-cheatsheet.git
Log | Files | Refs | README | LICENSE

2fa-bypass.md (7998B)

      1 ---
      2 title: "2FA/MFA/OTP Bypass"
      3 section: "Web Pentesting"
      4 sectionSlug: "pentesting-web"
      5 sourcePath: "src/pentesting-web/2fa-bypass.md"
      6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/pentesting-web/2fa-bypass.md"
      7 sha: "188de82beb54e70956b2952367a0af91d26758b8"
      8 isIndex: false
      9 modified: true
     10 license: "CC-BY-NC-4.0"
     11 ---
     12 
     13 # 2FA/MFA/OTP Bypass
     14 
     15 ## **Enhanced Two-Factor Authentication Bypass Techniques**
     16 
     17 ### **Direct Endpoint Access**
     18 
     19 See [Proxmox VE](/hacktricks/network-services-pentesting/pentesting-web/proxmox-ve#tfa-state-confusion-to-a-full-api-ticket) for a product-specific example of client-selected TFA state.
     20 
     21 Try the post-login endpoint directly and verify that the server—not only the UI—requires completion of the MFA state. If an application incorrectly trusts navigation metadata, also test the correctly spelled HTTP **`Referer` header**; a secure implementation must not use it as proof of MFA.<sup>[[2]](#references)[[5]](#references)</sup>
     22 
     23 ### **Token Reuse**
     24 
     25 Reutilizing previously used tokens for authentication within an account can be effective.<sup>[[2]](#references)</sup>
     26 
     27 ### **Utilization of Unused Tokens**
     28 
     29 Test whether an unused token generated for your own test account is incorrectly accepted for another authorized test account. This checks that OTPs are bound to the correct account, session, purpose, and transaction.<sup>[[2]](#references)[[5]](#references)</sup>
     30 
     31 ### **Exposure of Token**
     32 
     33 Investigate whether the token is disclosed in a response from the web application.<sup>[[2]](#references)</sup>
     34 
     35 ### **Verification Link Exploitation**
     36 
     37 Using the **email verification link sent upon account creation** can allow profile access without 2FA, as highlighted in a detailed [post](https://srahulceh.medium.com/behind-the-scenes-of-a-security-bug-the-perils-of-2fa-cookie-generation-496d9519771b).<sup>[[3]](#references)</sup>
     38 
     39 ### **Session Manipulation**
     40 
     41 Initiate sessions for two authorized test accounts, complete MFA in one, and verify that its completion state cannot be transplanted into the other session. The backend must bind the MFA result to the same account and pre-authentication session.<sup>[[5]](#references)</sup>
     42 
     43 ### **Password Reset Mechanism**
     44 
     45 Investigating the password reset function, which logs a user into the application post-reset, for its potential to allow multiple resets using the same link is crucial. Logging in with the newly reset credentials might bypass 2FA.<sup>[[2]](#references)</sup>
     46 
     47 ### **OAuth Platform Compromise**
     48 
     49 Check whether a federated **OAuth/OIDC** login path enforces an assurance level equivalent to the application's password-plus-MFA path. Control of the upstream identity account may bypass the application's local MFA only when the relying party accepts that weaker federated session.<sup>[[5]](#references)</sup>
     50 
     51 ### **Brute Force Attacks**
     52 
     53 #### **Rate Limit Absence**
     54 
     55 The lack of a limit on the number of code attempts allows for brute force attacks, though potential silent rate limiting should be considered.<sup>[[1]](#references)[[2]](#references)</sup>
     56 
     57 Note that even if a rate limit is in place you should try to see if the response is different when the valid OTP is sent. In [**this post**](https://mokhansec.medium.com/the-2-200-ato-most-bug-hunters-overlooked-by-closing-intruder-too-soon-505f21d56732), the bug hunter discovered that even if a rate limit is triggered after 20 unsuccessful attempts by responding with 401, if the valid one was sent a 200 response was received.<sup>[[4]](#references)</sup>
     58 
     59 #### **Slow Brute Force**
     60 
     61 A slow brute force attack is viable where flow rate limits exist without an overarching rate limit.<sup>[[1]](#references)</sup>
     62 
     63 #### **Code Resend Limit Reset**
     64 
     65 Resending the code resets the rate limit, facilitating continued brute force attempts.<sup>[[1]](#references)</sup>
     66 
     67 #### **Client-Side Rate Limit Circumvention**
     68 
     69 If throttling exists only in JavaScript, replay the request directly and verify whether the server independently enforces per-account, per-session, and broader abuse limits.<sup>[[1]](#references)[[5]](#references)</sup>
     70 
     71 #### **Internal Actions Lack Rate Limit**
     72 
     73 Rate limits may protect login attempts but not internal account actions.<sup>[[1]](#references)</sup>
     74 
     75 #### **SMS Code Resend Costs**
     76 
     77 Excessive resending of codes via SMS incurs costs to the company, though it does not bypass 2FA.
     78 
     79 #### **Infinite OTP Regeneration**
     80 
     81 Endless OTP generation with simple codes allows brute force by retrying a small set of codes.<sup>[[1]](#references)</sup>
     82 
     83 ### **Race Condition Exploitation**
     84 
     85 Send the same OTP or recovery code concurrently and verify that validation and consumption are atomic. A race exists if more than one request can redeem a single-use value.<sup>[[5]](#references)</sup>
     86 
     87 ### **CSRF/Clickjacking Vulnerabilities**
     88 
     89 Exploring CSRF or Clickjacking vulnerabilities to disable 2FA is a viable strategy.<sup>[[1]](#references)[[2]](#references)</sup>
     90 
     91 ### **"Remember Me" Feature Exploits**
     92 
     93 #### **Predictable Cookie Values**
     94 
     95 Guessing the "remember me" cookie value can bypass restrictions.<sup>[[1]](#references)</sup>
     96 
     97 #### **IP Address Impersonation**
     98 
     99 Impersonating the victim's IP address through the **X-Forwarded-For** header can bypass restrictions.<sup>[[1]](#references)</sup>
    100 
    101 ### **Utilizing Older Versions**
    102 
    103 #### **Subdomains**
    104 
    105 Test whether subdomains expose older applications or authentication paths that lack the current MFA requirement.<sup>[[1]](#references)</sup>
    106 
    107 #### **API Endpoints**
    108 
    109 Older API versions, indicated by /v\*/ directory paths, may be vulnerable to 2FA bypass methods.<sup>[[1]](#references)</sup>
    110 
    111 ### **Handling of Previous Sessions**
    112 
    113 Terminating existing sessions upon 2FA activation secures accounts against unauthorized access from compromised sessions.<sup>[[1]](#references)</sup>
    114 
    115 ### **Access Control Flaws with Backup Codes**
    116 
    117 Immediate generation and potential unauthorized retrieval of backup codes upon 2FA activation, especially with CORS misconfigurations/XSS vulnerabilities, poses a risk.<sup>[[1]](#references)[[2]](#references)</sup>
    118 
    119 ### **Information Disclosure on 2FA Page**
    120 
    121 Sensitive information disclosure (e.g., phone number) on the 2FA verification page is a concern.<sup>[[1]](#references)</sup>
    122 
    123 ### **Password Reset Disabling 2FA**
    124 
    125 A process demonstrating a potential bypass method involves account creation, 2FA activation, password reset, and subsequent login without the 2FA requirement.<sup>[[2]](#references)</sup>
    126 
    127 ### **Decoy Requests**
    128 
    129 Utilizing decoy requests to obfuscate brute force attempts or mislead rate limiting mechanisms adds another layer to bypass strategies. Crafting such requests requires a nuanced understanding of the application's security measures and rate limiting behaviours.
    130 
    131 ### OTP Construction errors
    132 
    133 If the OTP is derived only from predictable or client-supplied data, a user may be able to reproduce it. Verify that codes are generated from a cryptographically secure secret, are short-lived, single-use, and bound to the correct account and action.<sup>[[5]](#references)</sup>
    134 
    135 ## References
    136 
    137 - [1] [Two-Factor Authentication: Security Testing and Possible Bypasses](https://medium.com/@ISecMax/two-factor-authentication-security-testing-and-possible-bypasses-f65650412b35)
    138 - [2] [2 Factor Authentication Bypass](https://azwi.medium.com/2-factor-authentication-bypass-3b2bbd907718)
    139 - [3] [Behind the Scenes of a Security Bug: The Perils of 2FA Cookie Generation](https://srahulceh.medium.com/behind-the-scenes-of-a-security-bug-the-perils-of-2fa-cookie-generation-496d9519771b)
    140 - [4] [The $2,200 ATO Most Bug Hunters Overlooked by Closing Intruder Too Soon](https://mokhansec.medium.com/the-2-200-ato-most-bug-hunters-overlooked-by-closing-intruder-too-soon-505f21d56732)
    141 - [5] [OWASP Multifactor Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html)