cozyxss | Bug Bounty

This post details my step-by-step process for solving an authentication lab on PortSwigger Academy. The lab effectively demonstrated how subtle vulnerabilities in login mechanisms, such as response timing differences and IP-based blocking, can be exploited to compromise user credentials.

Section 1: Solution Steps and Key Observations

Step 0: Preparation and Setup

I started by saving the lab’s provided wordlists into two local files: usernames.txt and passwords.txt. I then accessed the lab’s login page, intercepted a login request using Burp Suite, and sent this request to both the Repeater and Intruder tools for further analysis.

Step 1: Initial Testing and Critical Observations

Using the provided credentials wiener:peter, I began testing the login behavior.

• First, I logged in with the username wiener and a deliberately incorrect password, test. In Burp Suite’s Repeater, I noticed the response took approximately 131ms.
• Next, I logged in with the correct password, peter. This time, the response was faster, around 81ms.
• Intrigued, I continued testing with the wrong password but started using very long strings. I observed a direct correlation: the longer the incorrect password, the longer the response time. This indicated the application was taking time to process the password.
• For comparison, I tried a non-existent username with a wrong password, which resulted in a consistently short response time, regardless of password length.

Another critical behavior emerged: after four consecutive failed login attempts, the application blocked the source IP address.

Key Takeaway 1: Bypassing IP Blocks with the X-Forwarded-For Header

To bypass the IP block, I added the X-Forwarded-For HTTP header to my requests. This header is typically used by proxy servers to indicate the original IP address of a client connecting through them. By spoofing this header with a new IP address for every few requests (e.g., X-Forwarded-For: 1, X-Forwarded-For: 2, etc.), I could trick the application into thinking the requests were coming from different machines, effectively bypassing the IP-based rate limit.

• Purpose of X-Forwarded-For: It’s a standard header for identifying the originating IP address of a client connecting to a web server through an HTTP proxy or load balancer.
• The Exploit: While it’s meant to be set by trusted proxies, if the application blindly trusts this header for client identification, an attacker can manually set it to bypass IP-based security controls.

Key Takeaway 2: The Significance of Response Timing

The timing analysis revealed the application’s authentication logic:

1. It first checks if the username exists.
2. Only if the username is valid does it proceed to check the password.
3. The password check likely uses a character-by-character comparison, which takes longer for longer strings. This creates a measurable timing difference that can be used for enumeration.

The conclusion was clear: a request with a valid username and a long, incorrect password will have a significantly longer response time than a request with an invalid username.

Step 2: Username Enumeration using Timing Attacks

With the insights from Step 1, I configured a Burp Intruder attack to find the valid username.

• Attack Type: Pitchfork.
• Payload Positions: I set two payload positions: one in the username field and another in the X-Forwarded-For header (to avoid blocks).
• Payloads:
  • Payload Set 1 (Usernames): The usernames.txt list.
  • Payload Set 2 (IPs): A list of numbers from 1 to 100 (e.g., X-Forwarded-For: 1, 2, 3…).
• Password: I used a single, very long password string (e.g., aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa) for every request to amplify the timing difference.

After running the attack, I sorted the results by the “Response Received” time. The request with the longest response time uniquely identified the correct username.

Key Takeaway 3: Why the Pitchfork Attack was the Right Choice

The Pitchfork attack type uses one payload set for each position and iterates through them in parallel. This was perfect for our scenario because:

• We needed to pair each username from our list with a unique X-Forwarded-For IP value to avoid triggering the block.
• Using a Cluster Bomb attack (which tests all combinations of all payload sets) would have been inefficient and unnecessary, generating 100 usernames * 100 IPs = 10,000 requests. Pitchfork kept it lean and effective with just 100 requests, perfectly synchronizing the two payload lists.

Step 3: Password Enumeration

After identifying the valid username, I moved on to brute-forcing the password using a similar setup.

• Attack Type: Pitchfork (again, to manage the IP block).
• Payload Positions: One in the password field and another in the X-Forwarded-For header.
• Payloads:
  • Payload Set 1 (Passwords): The passwords.txt list.
  • Payload Set 2 (IPs): A new set of numbers (e.g., 101-200).
• Username: The validated username from the previous step.

This time, instead of timing, I looked for a different signal: a successful login attempt. The attack quickly identified the correct password, which was indicated by an HTTP 302 status code (signifying a redirect after successful authentication) and a different response length compared to failed attempts.

Section 2: Lessons Learned

2.1 IP-Blocking and the X-Forwarded-For Header

IP-based blocking is a common but often weak defense mechanism. It can frequently be bypassed if the application trusts client-supplied headers like X-Forwarded-For, X-Real-IP, or X-Originating-IP. Security controls should never rely solely on IP addresses that can be spoofed; instead, they should use more robust methods or ensure that such headers are only set by trusted, internal infrastructure.

2.2 The Power of Timing Attacks

Even minute differences in processing time can leak critical information. Applications must be designed to use constant-time comparison functions for sensitive operations like password checking to prevent attackers from inferring valid user data.

2.3 Choosing the Right Attack Type in Burp Intruder

Understanding the different Intruder attack types is crucial for efficiency:

• Sniper: Tests a single payload position with one list.
• Battering Ram: Tests multiple positions with a single payload list.
• Pitchfork: Uses multiple payload sets in parallel (ideal for correlating data like username/IP).
• Cluster Bomb: Uses multiple payload sets to test all possible combinations (ideal for brute-forcing usernames and passwords without a block).

Section 3: References and Further Reading

• OWASP:
  • OWASP Testing Guide: Testing for Weak Lockout Mechanism
• HTTP Headers:
  • MDN Web Docs: X-Forwarded-For

For more updates and to follow my journey, connect with me on:

Github| X