Lab 5: Username enumeration via account lock:
This lab is vulnerable to username enumeration. It uses account locking, but this contains a logic flaw. To solve the lab, enumerate a valid username, brute-force this user’s password, then access their account page.
Candidate usernames Candidate passwords
Initial Reconnaissance/Discovery:
As usual we have access to a web page which has a “My account” section.
Let’s enter some creds we know won’t work to see the response.
So we get a standard response: “Invalid username or password”
Enumerating Usernames By Forcing Account Lockout:
Manual Method:
Taking the POST request for login, we can send it to burp intruder and set our injection point as the username and paste in the list of supplied usernames. We are doing this to see if we get any other form of response e.g. if the username is valid but the password wrong will we get a some sort of different response.
We will get no useful responses from just doing the attack once, however if we perform the attack 5 times in quick succession and filter our response size by length we can see that the user “arizona” has the message “You have made too many incorrect login attempts. Please try again in 1 minute(s).”
This means we have used the websites “safety” mechanism as a means to enumerate valid users
Using Automated Null Payloads For Username Enumeration:
Now the above method of quickly re-issuing the attack 5 times manually worked but this is not a great way to do this as it’s error prone. Instead we can use a built in feature of burp which allows us to try payloads with a NULL x amount of times.
To do this we do the following:
- Select the username value & the password value as injection points.
- Ensure there is some sort of value in the password field also. It can be any value.
- Select the “Cluster bomb attack” type.
- For the password position select the payload type of “Null payloads”
- Set the “Payload configuration” generate value to 5.
Once we start the attack we can see we get a hit.
+Important+: For this to be effective we would need to know the lockout policy attempt value. The easiest way to do this is to set the “generate” value to something high meaning that if we do hit on a real username we will ensure we hit the lockout value and get confirmation.
Bruteforcing The Password:
We can now take the username and bruteforce using the password list. We repeat what we did before but this time setting the injection point as the password field and using the supplied list of passwords.
Looking through the results in intruder we can see there is a response with a shorter length for the password “hunter”.
If we check that cominbation after waiting 1 minute we can see it works and we are logged in.
Understanding The Logic Of This Vulnerability:
Now this approach above doesn’t really make much sense as after 5 incorrect login attempts the account is locked out for 1 minute. So is it just by chance we found the correct password…well…no…as I retried the lab to ensure my findings were valid.
How this works is:
Invalid Username: If we try an invalid username we get the response “Invalid username or password”
Valid Username: If we try a valid username and hit the lockout limit due to incorrect password being entered we get the response “You have made too many incorrect login attempts. Please try again in 1 minute(s)."
Valid Username & Password: However even if we hit the lockout limit with a valid username if we enter the valid password we still get a standard 200 response with no message (see below) this means we can infer valid usernames & passwords by the applications response & bypass the lockout policy too.
