Portswigger's "Username enumeration via different responses" Walkthrough
This is the first of Portswigger’s Authentication Labs. Before we get started, you’ll need Burp Suite installed (check out this blog post for setup instructions), and an Portswigger Academy account.
After logging in, head over to the lab, located at https://portswigger.net/web-security/authentication/password-based/lab-username-enumeration-via-different-responses. You can find this through the Academy learning path list, or linked within the Authentication blog post.
Note: the correct answers vary between lab sessions, so you need to follow the steps to find the correct values for your lab session.
Challenge Information
Click the “Access the Lab” button and you will be taken to a temporary website that is created for your account. This will be in format https://<random string here>.web-security-academy.net/.
Vulnerability overview
The challenge is focused on authentication issues where the “wrong username” case is handled with a different message than the “wrong password” case.
This allows an attacker to first try out all the usernames they can think of to discover which ones are valid. Then, with the narrowed-down list of valid usernames, they can try common or known passwords.
This significantly reduces the scope of the attack. If you have 100 usernames and 100 passwords (as we will in just a moment), that’s 10,000 different combinations (each username with each password).
If you can narrow down the username list down to 1 valid username first, then try out the 100 passwords for that user, that’s at most 200 requests.
Challenge materials
We’re given a username list and a password list:
Keep these two tabs open, we’ll need them in a minute.
Challenge website
The challenge website looks like this:
Click “My Account” to login:
Then, with Burp Suite open and your proxy running, submit a fake set of credentials such as test/test. In Burp Suite, go to the Proxy tab, find this request, right-click it and select Send to Intruder.
Intruder Setup
In the Intruder tab, a few modifications need to be made.
First off, the § character around a string denotes that it’s a variable. We can use these variables to insert values of our choosing, such as a username or password wordlist.
Burp Suite Intruder will typically auto-select values that it thinks are variables:
In this screenshot, it has selected the session cookie, username, and password as variables.
We need to first remove the session cookie as a variable. Select just the green value (including § characters) after session= then click the “Clear” button on the righthand side of the page.
The page should now look like this:
Repeat this process for the password value:
Bruteforcing the Username
Now we’re ready to start bruteforcing the username. As mentioned before, we know that this is a username enumeration attack, so we’ll first find the username, then we’ll go back and bruteforce the password.
Click the “Payloads” tab. Copy the usernames from the username list provided, then click Paste in the Payload Options section.
The Payload Sets options have different styles of injecting values into the variables. For this attack, we only need a simple list.
With the username values in the list, click “Start Attack”. This will open a new window that will show the results of 100 different queries, one for each username. If you are using the free version of Burp Suite, this attack will be throttled and may take a few minutes to complete.
After several requests, you’ll notice that one has a shorter response length than the others.
The username ftp has a response length of 2986, instead of 2984 like all the other responses. Note that your username value might be different. If that’s the case, just sub out ‘ftp’ for your found value for the rest of this post.
If you look at the Response tab for the ftp username request, you’ll see that it says “Incorrect password”.
Compared to any of the other requests, which say “Invalid username”.
That means we’ve found our valid username, ftp. Close the pop-up window to stop the attack, if it is still running.
Bruteforcing the password
Now we need to bruteforce the password, given the valid username of ftp. Go back to the Positions tab and hardcode ftp as the username. Then select the password test value (or whatever your fake password value is) and click the “Add” button on the righthand side to turn it into a variable.
Next, go to the Positions tab and clear the payload list. With the username list removed, you’ll need to copy the passwords list that was provided, and then click Paste to populate the password payload list:
Click “Start Attack” to begin trying the different passwords with the known good username.
Eventually, there will be a request where the password length differs:
Again, your value might be different, as Portswigger labs seems to randomize this.
Click into the Response for this request, and see that it’s a 302 redirect:
This response is redirecting us to /my-account, so the password must be correct. The correct password for this session is aaaaaa. The response lengths after this request will be a different length, since we’ll have a valid cookie at that point.
With the username and password found in the previous steps (which, again, will differ from the ones shown here because the values are randomized), log in:
And the lab will be completed!
