Listen to this Post
Introduction:
In the fast-paced world of bug bounty hunting, the allure of discovering a novel zero-day vulnerability often overshadows a more accessible, yet highly lucrative, strategy: retesting previously patched bugs. As Application Security Researcher Divyank Sitapara recently demonstrated, a “fix” is not always a permanent solution. By understanding the mitigation applied and creatively bypassing it, hunters can uncover residual flaws, logic errors, and incomplete patches that programs have already paid for once, making them highly likely to pay again.
Learning Objectives:
- Understand the methodology for analyzing and bypassing existing vulnerability patches.
- Master essential command-line and proxy tools for effective retesting workflows.
- Develop a systematic approach to uncover logic flaws and business logic errors in remediated issues.
You Should Know:
- Intercepting and Modifying Patched Requests with Burp Suite
The first step in retesting is to understand how the original vulnerability was fixed. This often involves intercepting a now-blocked request and analyzing the server’s response.
Step-by-Step Guide:
- Step 1: Configure your browser to use Burp Suite as an intercepting proxy.
- Step 2: Navigate to the functionality that was previously vulnerable and trigger the request that was patched.
- Step 3: In Burp, send the intercepted request to Repeater (Right-click > Send to Repeater). This allows for manual manipulation.
- Step 4: Analyze the original patch. Was it a client-side check? A new parameter? A header validation? Systematically modify each part of the request:
- Change the HTTP method from `POST` to `GET` or vice versa.
- Add headers like `X-Forwarded-For: 127.0.0.1` or
X-Original-URL: /admin. - URL-encode, double-URL-encode, or even lowercase/uppercase key parameters.
- Step 5: Observe the server’s response for differences. A 200 OK where a 403 Forbidden is expected is a strong indicator of a bypass.
2. Fuzzing for Parameter Pollution via Command Line
Incomplete input sanitization is a common flaw in patches. Server-side parameters can often be polluted with multiple values to confuse the parsing logic.
Verified Command & Guide:
`ffuf -w /usr/share/wordlists/parameter-names.txt -u “https://target.com/endpoint?FUZZ=payload&original_param=value” -fs 0`
– What it does: This command uses ffuf, a fast web fuzzer, to test for hidden parameters that might override the patched validation.
– Step 1: Install `ffuf` (go install github.com/ffuf/ffuf@latest).
– Step 2: Craft your target URL, replacing the parameter you are testing with FUZZ.
– Step 3: The `-fs 0` filter hides responses of size 0 (typically errors). You are looking for a response size that differs from the standard “invalid request” response.
– Step 4: If a new parameter like `bypass_token` or `validation_key` is found, experiment with its value to see if it disables the security check.
3. Bypassing Client-Side Controls with cURL
Many quick fixes implement validation solely in JavaScript, which is trivial to bypass by sending requests directly to the server.
Verified Command & Guide:
`curl -X POST https://target.com/api/changeEmail -H “Content-Type: application/json” -H “X-Requested-With: XMLHttpRequest” -d ‘{“email”:”[email protected]”}’`
– What it does: This `curl` command sends a direct POST request, completely ignoring any client-side JavaScript validation.
– Step 1: Use Burp Suite to capture the legitimate request after the patch.
– Step 2: Note all headers (like CSRF-Token, Cookies) and the JSON/XML structure.
– Step 3: Replicate this request using curl, ensuring all headers and session cookies are included. The key is to change the critical value (e.g., user ID, email address) to one you shouldn’t have access to.
– Step 4: If the server processes the request without the client-side checks, the patch is ineffective.
4. Testing for SQLi Patch Bypasses with Sqlmap
A common patching mistake is using a denylist of dangerous keywords instead of prepared statements. This can be bypassed with obfuscation.
Verified Command & Guide:
`sqlmap -u “https://target.com/vulnerable-page?id=1” –tamper=charencode,space2comment –level=3 –risk=2`
– What it does: `sqlmap` automates SQL injection detection. The `–tamper` scripts obfuscate the payload to evade simple filters.
– Step 1: Identify the parameter that was previously vulnerable to SQLi.
– Step 2: Use `sqlmap` with tampering scripts. `charencode` will URL-encode the payload, while `space2comment` replaces spaces with //, which are often ignored by SQL parsers.
– Step 3: The `–level` and `–risk` flags increase the sophistication and number of tests performed. A successful detection indicates the patch was insufficient.
5. Analyzing Access Control Bypasses via Forced Browsing
A patch might block access to `/admin` but forget about /Admin, /admin/../admin, or /console.
Verified Command & Guide:
`gobuster dir -u https://target.com/admin -w /usr/share/wordlists/dirb/common.txt -x php,html,json,txt`
– What it does: `Gobuster` performs directory and file brute-forcing to find hidden resources.
– Step 1: Target the general area of the patched vulnerability (e.g., /admin, /api).
– Step 2: Run the command. The `-x` flag checks for files with these extensions.
– Step 3: Review the results for alternative paths or backup files (e.g., /admin.old, /admin.php, /api/v1/backup) that may not have the same access controls applied.
6. Exploiting Race Conditions in Rate-Limiting Patches
A newly implemented rate limit on an action (e.g., promo code redemption) might be vulnerable to race condition attacks where multiple requests are sent simultaneously.
Verified Command & Guide:
`for i in {1..50}; do curl -X POST https://target.com/redeem -d “code=GIFT50” & done`
– What it does: This bash command sends 50 POST requests in parallel (background jobs) to the redemption endpoint.
– Step 1: Identify an action that should only happen once per user but now has a rate limit.
– Step 2: Run the command. The `&` at the end of the `curl` command runs each process in the background, causing them to hit the server nearly simultaneously.
– Step 3: Check the result. If you receive the benefit (e.g., credit, coupon) more than once, the race condition patch is flawed.
7. Leveraging Wayback Machine for Historical Context
Understanding what changed in the application’s front-end can provide clues for the bypass. Old JavaScript files might reveal the logic of the original vulnerability.
Verified Command & Guide:
`waybackurls target.com | grep “\.js$” | sort -u > js_files.txt`
– What it does: This pipeline uses `waybackurls` (from the `gobuster` suite) to fetch historical URLs for the target, filters for JavaScript files, and saves them.
– Step 1: Install `waybackurls` (go install github.com/tomnomnom/waybackurls@latest).
– Step 2: Run the command to get a list of archived JS files.
– Step 3: Manually review these files for client-side logic, API endpoints, or parameters that may have been removed or modified in the current version but are still active on the backend.
What Undercode Say:
- The Fix is Often the Flaw: The most critical takeaway is that the patch itself introduces a new attack surface. By focusing on the implementation of the fix rather than the original bug, you shift your perspective to where the defense is newest and weakest.
- Persistence Pays Dividends: Retesting is not a one-off activity. As an application evolves, old patches can break, new features can re-introduce old problems, and code merges can revert security changes. Building a personal database of previously reported bugs and scheduling periodic retests is a highly professional and profitable strategy.
Analysis: Sitapara’s experience underscores a fundamental truth in application security: remediation is a process, not an event. Development teams, pressured to fix issues quickly, often implement tactical patches that address the specific proof-of-concept rather than the root cause vulnerability class. This creates a “Whac-A-Mole” scenario where the same underlying flaw manifests differently. For the bug bounty hunter, this is an opportunity. It requires a shift from a breadth-first approach (scanning everything) to a depth-first approach (mastering a specific feature’s history and security lifecycle). This methodical, almost archaeological, investigation of an application’s security history is less crowded and demonstrates a higher level of skill to the program administrators, often leading to larger bounties and a respected reputation.
Prediction:
The practice of retesting fixed vulnerabilities will evolve from an opportunistic tactic to a formalized, automated component of continuous penetration testing. We will see the rise of specialized tools that integrate with platforms like HackerOne and Bugcrowd to automatically track a hunter’s submitted reports, monitor application deployments for changes, and suggest retesting strategies when a patch is deployed. Furthermore, as AI-assisted code fixing becomes more prevalent, it will introduce a new class of patch-related flaws based on AI misunderstandings of vulnerability context, creating a fresh “bypass-the-bot” subfield for ethical hackers. The hunters who systematize the art of the retest will be the ones consistently finding value long after the initial low-hanging fruit has been picked.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Divyank Sitapara – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
