Authentication Vulnerabilities
Lab: Username enumeration via different responses
This lab is vulnerable to username enumeration and password brute-force attacks. It has an account with a predictable username and password, which can be found in the following wordlists:
To solve the lab, enumerate a valid username, brute-force this user's password, then access their account page.
Solution
First, we will go to the login page.
Next, we will intercept the request to login and send to intruder.
First, we will enumerate the username.
We will set the payload position to be at username parameter.
For the wordlist, we will use the wordlist that they provided for us.
Lastly, we can start the attack.
After looking at the result, we realised that one of the request gave a different response from the others
From here, we can deduce that the username is acceso.
Next, we will enumerate the password.
This time we will set payload position to be on the password parameter.
This time the wordlist used is for passwords instead.
After reviewing all the result, we can see that 1 of the responses is returning 302. This means that the password must be correct. The password is joshua.
After keying in the credentials, we are able to login.
Lab: Username enumeration via subtly different responses
This lab is subtly vulnerable to username enumeration and password brute-force attacks. It has an account with a predictable username and password, which can be found in the following wordlists:
Candidate usernames
Candidate passwords
To solve the lab, enumerate a valid username, brute-force this user's password, then access their account page.
Solution
We will do the same thing as the previous labs and capture the login request.
We will also do the same thing for the payload position for the username.
After reviewing, the result it looks like all the username return the same response.
We can see that the response is Invalid username or password.
What if there is a response that does not match this, it could mean that the username on the request might be correct.
Burp Suite has an inbuilt filter which is able to return the negative result instead.
After applying, we can see that there is 1 request that is not the same as the rest.
If we look closely at the response, we can see that the message that was returned does not come with a .
Now we will set the payload position to be at the password parameter.
The wordlist we will use is the password wordlist that they provided.
Finally, we can start the attack.
After reviewing the result, we can see that 1 of the responses returns a 302 instead of 200. This suggest that the password that is used might be correct.
After trying the credential, we are able to login.
Lab: Username enumeration via response timing
Your credentials:
wiener:peterCandidate usernames
Candidate passwords
This lab is vulnerable to username enumeration using its response times. To solve the lab, enumerate a valid username, brute-force this user's password, then access their account page.
Solution
We will do the same thing as the previous labs and capture the login request.
They mentioned that the application is vulnerable to username enumeration using response times. So it might be case where the incorrect username takes very to sending back the response but the correct username takes very long to check depending on the password length.
So we will modify the request to this:
We will then send this request to Intruder.
Next, we will set the payload position to be at the username parameter.
The wordlist that is to be used is the wordlist that they provided.
However, after some failed login attempts, the application blocked us from trying to attempt to login.
So to bypass this issue, we can change the attack type to Pitchfork.
We will also add X-Forwarded-For header into the request and the value of that header to be added as another payload position.
For payload set 1, we will use all numbers.
For payload set 2, we will use the word list that they have provided.
After running the attack, we can see that there is a request that has a very long response time.
We can try that as the username. Now we will try to brute force the password.
After reviewing the result, we can see that the password is daniel.
After trying the credentials, we should be able to login.
Lab: Broken brute-force protection, IP block
This lab is vulnerable due to a logic flaw in its password brute-force protection. To solve the lab, brute-force the victim's password, then log in and access their account page.
Your credentials:
wiener:peterVictim's username:
carlosCandidate passwords
Solution
Same as the previous lab, we will use X-Forwarded-For to bypass the IP block.
We will set te attack type to Pitchfork
We will then set the payload to at these 2 location
For the 1st payload set, we will set this:
For the 2nd payload set, we will use the wordlist that was provided.
However, after running this attack, they are blocking after 3 incorrect attempts.
So we will modify the attack to use another method since we know that they are blocking after 3 incorrect attempts.
We will first change the payload position to both the username and password parameter
Next, we will write create a password.txt to store all the password that they have provided.
After that, we will run this script to generate modified_password.txt and modified_username.txt.
Finally we will upload modified_username.txt for set 1.
And upload modified_password.txt for set 2
We will also ensure that the request is sent 1 at the time if not the IP will get blocked again.
After the attack is finished running, we will then filter the result with this:
There should only be 1 result that is returned which is this:
We can see the password is jordan. From here, we should be able to login as carlos
Lab: 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
Solution
Same as the previous lab, we will capture the request for login using Burp Suite and send that request to Intruder
For the payload position, we will put it at the username parameter
For the payload, we will use their username wordlist
After running the attack once, we can see that the all the error messages in the responses are the same.
We can try to force the valid account to be locked out after multiple incorrect attempts. So we will rerun the same attack 4 more times as the usually after the 4th failed attempt, the account will get locked out.
We can see that the valid username is al.
So now we will shift our payload position from username to password parameter
For the payload, we will use the given wordlist for passwords
After reviewing the result, there was 1 response that did not return any error message. This means that could the correct password for the account. We will try with those credentials
After trying with those credentials, we are able to login
Lab: 2FA simple bypass
Your credentials:
wiener:peterVictim's credentials
carlos:montoya
This lab's two-factor authentication can be bypassed. You have already obtained a valid username and password, but do not have access to the user's 2FA verification code. To solve the lab, access Carlos's account page.
Solution
So, first we will capture how the full login process works.
Firstly, the client will send a POST request to /login
If the login credential is valid, we can see that the client will retrieve the web page that is used for 2FA
After which, the user will enter the 2FA code that was send to the user's email.
We could try to see if we can bypass the 2FA page by going to the My Accounts page after successfully logging in.
It turns out we can just visit the webpage after logging in.
Lab: 2FA broken logic
This lab's two-factor authentication is vulnerable due to its flawed logic. To solve the lab, access Carlos's account page.
Your credentials:
wiener:peterVictim's username:
carlos
You also have access to the email server to receive your 2FA verification code.
Solution
We will do the same initial steps as the previous lab.
However, if we inspect the request when we are requesting /login2, we can see the cookie is set as verify=wiener. We can change this to verify=carlos and this should send a OTP code to carlos.
However, we do not have access to carlos email, so we will try to brute force the OTP code that is used to login. First we will capture the request that is use to valid the OTP code and send that request into Intruder.
We will put the payload position at mfa-code parameter
We will set this as the payload:
We can see that 1 of the responses returns 302.
This means that this should be the correct 2FA code.
We can try to enter the 2FA code with the modified cookie.
We should be able to login as carlos
Lab: Brute-forcing a stay-logged-in cookie
This lab allows users to stay logged in even after they close their browser session. The cookie used to provide this functionality is vulnerable to brute-forcing.
To solve the lab, brute-force Carlos's cookie to gain access to his "My account" page.
Your credentials:
wiener:peterVictim's username:
carlosCandidate passwords
Solution
First, we will try to login and check the Stay logged in.
There is nothing special on the request
However, there is a cookie that is set for the request to get /my-account?id=<username>.
If we try to decode the content of stay-logged-in with base64, this is what we are returned with:
The 2nd part looks like a hash, we will use hash analyzer to check what kind of hash it is
We can see that the hash used is MD5.
So now, we will try to crack it and see what is the original value using crackstation
We can see that the it is the password for wiener.
So with this logic, we can craft brute force a stay-logged-in cookie.
The format of the cookie is:
So we will set the GET request to Intruder
We will modify the request and set the payload position as shown below
The payload we will use the password list
We will also add these payload processing rules
We can see that 1 of the response will return 200 instead of 302. This means the cookie is valid.
Then we can just modify the stay-logged-in cookie value on the web browser, remove all the session and refresh, it should bring us to the correct user.
Lab: Offline password cracking
This lab stores the user's password hash in a cookie. The lab also contains an XSS vulnerability in the comment functionality. To solve the lab, obtain Carlos's stay-logged-in cookie and use it to crack his password. Then, log in as carlos and delete his account from the "My account" page.
Your credentials:
wiener:peterVictim's username:
carlos
Solution
First we go into any post
Then, we will go to end of the web page, we should be able to see this
We can try to inject an XSS payload into the comment section
We can see that our payload has been successfully uploaded
When we go back to the post, we will see this.
This means the XSS payload is successfully injected.
So the next payload that we can craft is an stored XSS payload that steals session cookie from any users that is visiting the post.
First, we need to note what is the URL of the exploit server
This is what the payload should look like
After we submit, we will check the logs of the exploit server to see if the cookie is being transmitted there.
Sure enough, the cookie is visible on the logs
We can URL decode to get the value of both cookies
Next, we will decode the value of stay-logged-in using base64. It should return us this
From the previous labs, we know the hash that they used is MD5, we can just use crackstation to get the password from the hash.
The password for carlos is onceuponatime
With these credential, we are able to delete carlos account.
Lab: Password reset broken logic
Your credentials:
wiener:peterVictim's username:
carlos
This lab's password reset functionality is vulnerable. To solve the lab, reset Carlos's password then log in and access his "My account" page.
Solution
We will try to reset the password for wiener
After which, we should be able to see this email on the client's email
After clicking on the link, we will try to reset the password.
From there, we will capture this request using burp
So we can try to change the username to carlos instead and send this request instead.
After sending, it did not pop up any error message.
We should be able to login as carlos with the new password set.
Lab: Password reset poisoning via middleware
This lab is vulnerable to password reset poisoning. The user carlos will carelessly click on any links in emails that he receives. To solve the lab, log in to Carlos's account. You can log in to your own account using the following credentials: wiener:peter. Any emails sent to this account can be read via the email client on the exploit server.
Solution
First we will capture the request of generating the OTP for the password reset and send to Repeater
We will then modify the request to as shown below:
We will go to the logs and see if we can see the reset password token there.
So the next step, we will send the password reset request to Repeater.
We will modify the request to this:
After sending, it should not have any error showing in the response
We should be able to log in as carlos with the new password set.
Lab: Password brute-force via password change
This lab's password change functionality makes it vulnerable to brute-force attacks. To solve the lab, use the list of candidate passwords to brute-force Carlos's account and access his "My account" page.
Your credentials:
wiener:peterVictim's username:
carlosCandidate passwords
Solution
First, we will capture the password reset request using burp suite after we have login.
After playing around with it, we notice something interesting.
If we put the correct password, but the new password are not the same. They will return this error message.
If we put the wrong password, but the new password are not the same. This will return this error message instead.
With this logic, we can get the password for carlos by brute-forcing and checking the error message in the responses.
First, we will send the request for the password change to Intruder
We will modify the request and set the payload position to what is shown below.
For the payload, we will use the password list that they have provided
After reviewing the results, we can see that there is 1 response that does not match the rest.
From here, we should be able to login as carlos
Last updated