Listen to this Post
Introduction:
Two-Factor Authentication (2FA) is a cornerstone of modern account security, but a common misconfiguration—insufficient rate limiting—can transform this defense mechanism into a lucrative attack vector for ethical hackers. By bombarding the 2FA verification endpoint with rapid-fire requests, attackers can brute-force codes, leading to account compromise and significant bug bounty rewards.
Learning Objectives:
- Understand the fundamental mechanics of a 2FA rate limiting vulnerability.
- Learn to identify endpoints susceptible to this attack during reconnaissance.
- Master the use of automated tools like Burp Intruder and custom scripts to test for and exploit this flaw.
You Should Know:
1. Identifying the 2FA Submission Endpoint
The first step is pinpointing the exact API endpoint or web form that receives the 2FA code for validation. This is often done by intercepting the request after submitting a login attempt that triggers a 2FA prompt.
` Use Burp Suite Proxy to intercept the 2FA submission request.`
` Look for a POST request to a path like /api/2fa/verify, /2fa/check, or /verify-2fa.`
` The request body will typically contain a parameter such as “code”, “token”, or “2fa_code”.`
Step-by-step guide:
- Log in to a target application with valid credentials.
- When prompted for a 2FA code, open your browser’s developer tools or Burp Suite Proxy.
- Enter any 6-digit code (e.g., 123456) and click “Verify”.
- In your intercepting proxy, you will capture the HTTP request being sent to the server. Note the URL, HTTP method (usually POST), and the parameter name holding the code.
2. Crafting the Basic Attack Request
Once you have identified the endpoint and parameter, you can craft a request for testing. This raw HTTP request is the foundation for your attack.
`POST /api/v1/2fa/verify HTTP/1.1`
`Host: target.com`
`User-Agent: Mozilla/5.0…`
`Cookie: session=your_session_cookie_here;`
`Content-Type: application/x-www-form-urlencoded`
`Content-Length: 13`
`code=§123456§`
Step-by-step guide:
- Send the intercepted 2FA verification request to Burp Suite’s Repeater tool.
- In Repeater, change the code parameter to a simple value like
123456. - Send the request and observe the response. A “200 OK” or “302 Found” might indicate success, while a “401 Unauthorized” indicates failure. You need to establish a baseline for both success and failure responses.
3. Automating the Attack with Burp Intruder
Manually sending requests is inefficient. Burp Intruder allows you to automate the attack by bombarding the endpoint with a payload of possible codes.
` In Burp Suite, right-click the request in Proxy history or Repeater and select “Send to Intruder”.`
` In the Intruder Positions tab, clear any auto-selected payload positions.`
` Highlight the value of the “code” parameter (e.g., 123456) and click “Add §”.`
` This will mark the code value as the payload position: code=§123456§`
Step-by-step guide:
1. Configure the Attack type to “Sniper”.
- Go to the Payloads tab. For a 6-digit numeric code, set the Payload type to “Numbers”.
- Configure the range from 0 to 999999, with a step of 1. Set the number format to 6 digits with leading zeros (e.g., 000000, 000001, …, 999999).
- In the Options tab, you may need to adjust the “Grep – Match” settings to automatically flag responses that differ from the failure baseline (e.g., different length, status code, or content).
- Start the attack. Intruder will rapidly iterate through all 1 million possible codes.
4. Bypassing Weak Rate Limiting
If the attack above is successful, the target has no rate limiting. Often, a weak implementation will exist. You may need to manipulate headers or session tokens to bypass simplistic counters.
` If requests are blocked after a few attempts, try adding these headers to evade detection:`
`X-Forwarded-For: 127.0.0.1`
`X-Originating-IP: 127.0.0.1`
`X-Remote-IP: 127.0.0.1`
`X-Real-IP: 127.0.0.1`
` Also, consider rotating the session cookie or user agent between requests.`
Step-by-step guide:
- If your Intruder attack gets blocked after 5-10 requests, the endpoint has a basic IP-based rate limit.
- Use the “Resource Pool” feature in Intruder to slow down the request rate (e.g., 1 request every 5 seconds).
- Alternatively, use the “Bash” payload type in Intruder to call `curl` with a different `X-Forwarded-For` header for each request, making the requests appear to come from different IPs.
5. Analyzing Responses for Success
The key to a successful automated attack is correctly identifying the response that indicates a correct code was found. This is often a change in HTTP status code, response length, or content.
` Use Burp Intruder’s “Grep – Match” feature to flag interesting responses.`
` Look for changes in:`
`- HTTP Status Code (e.g., 302 vs. 401)`
`- Response Length (a successful response will often be longer or shorter)`
`- Response Content (e.g., absence of the text “Invalid code”)`
Step-by-step guide:
- Before starting the attack, send one manual request with a wrong code and note the response length (e.g., 1254 bytes).
- In the Intruder Options tab, add the failure response length under “Grep – Extract”. You can then sort the attack results by this column to find any responses with a drastically different length.
- A successful login will often redirect the user. Filter for all responses with a 302 status code, as these are prime candidates for a successful bypass.
6. Advanced Bypass: Manipulating Timestamps
Some applications use client-side timestamps as a form of request uniqueness. If the server doesn’t properly validate these, they can be manipulated.
` If the request includes a timestamp parameter, it might be used for rate limiting.`
` You can use a payload processing rule in Intruder to generate a fresh timestamp for each request.`
` Example parameter: ×tamp=1663950123`
` Use a “Numbers” payload type that increments from the current epoch time.`
Step-by-step guide:
- If a `timestamp` or `nonce` parameter is present, note its format (e.g., Unix epoch).
- In the Payloads tab, set the payload type for that parameter to “Numbers”.
- Set the range to start from the current epoch time and increment by 1 for each request. This ensures every request has a unique timestamp, potentially bypassing duplicate request checks.
7. Ethical Reporting and Mitigation
Once you have successfully proven the vulnerability, it is crucial to report it ethically to the organization through their bug bounty program or security contact.
` A strong proof-of-concept (PoC) report should include:`
`1. Vulnerability “Missing Rate Limiting on 2FA Verification Endpoint”`
`2. Steps to Reproduce: A clear, step-by-step guide using the tools and methods described.`
`3. Impact: “Allows an attacker to bypass two-factor authentication, compromising any user account.”`
`4. Mitigation: “Implement strong rate limiting (e.g., 5 attempts per 15 minutes) and account lockout policies. Consider using exponentially increasing delays.”`
Step-by-step guide:
- Document every step you took, including the vulnerable endpoint URL.
- Provide screenshots of your Burp Intruder setup and the successful response that granted you access.
- Do not attempt to access any sensitive user data beyond what is necessary to prove the concept.
- Submit the report through the official channel and wait for the triage team’s response.
What Undercode Say:
- Pervasive Simplicity: The most critical takeaway is that this is not a complex cryptographic flaw but a simple, pervasive architectural oversight. Defenders often focus on the strength of the 6-digit code itself, forgetting to build a cage around the verification process. This makes it one of the most common and high-impact findings in modern web application bug bounty programs.
- Automation is Key: The difference between a theoretical vulnerability and a validated, paid bug bounty is automation. Manual testing cannot feasibly guess 1 million codes, but a basic understanding of Burp Intruder transforms an impossible task into one that takes minutes. Mastery of these tools is non-negotiable for professional bug hunters.
The analysis underscores a fundamental tension in cybersecurity: the reliance on cryptographic controls can create a false sense of security if the surrounding operational logic is weak. A 2FA code’s 1-in-a-million guessability is meaningless if an attacker is allowed to make a million guesses unimpeded. This vulnerability class is a perfect example of a broken logical flaw, not a broken cryptographic one, and it remains wildly profitable for hunters because it is so frequently overlooked in development and QA cycles.
Prediction:
The future of 2FA bypass vulnerabilities will shift from pure rate limiting misses to more sophisticated logic flaws within account recovery flows and session management post-verification. However, the core issue of missing rate limits will persist in API-first and serverless architectures, where traditional web application firewalls (WAFs) struggle to enforce stateful request counting across distributed systems. As push notification 2FA (e.g., “Number Matching” in Microsoft Authenticator) becomes standard, attackers will increasingly target the underlying approval APIs, making robust rate limiting not just an enhancement but an absolute necessity for core security hygiene.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Being Nice – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
