Password brute-force via password change
To access the lab visit the following link:
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:peter - Victim’s username:
carlos - Candidate passwords
Click on the given button to access the lab:
On the Lab’s homepage we can see “My account” option. Let’s click on that to attempt login.
Let’s login using correct username and password.
We are successfully logged in to the application and we can see change password option on the “My Account” page.
Let’s try to change password of Wiener and capture the request in burp HTTP History. In this case I used “test” as new password.
As soon as we click on “Change Password” button it says Password changed successfully!. Let’s click on “back” to see if we are still logged in or not.
And we are still logged in after changing password of wiener.
Let’s change password of wiener again and this time we will use incorrect current password. In this case I used “peter” as current password as we have already changed it to “test”.
As soon we click on “Change password” it redirects us to the login page. It means when we try to change password and we provide incorrect current password the application logs us out.
Here is the POST request of case 2 in burp HTTP History.
Let’s login again by using correct credentials and it activates the account lock for the next one minute.
This means that when we provide an incorrect password while attempting to change the password of a user, it will activate the account lock mechanism. This mechanism is designed to prevent brute force attacks.
Let’s login again after one minute and test for another scenario. This time we will provide incorrect current password and mismatched new passwords.
Upon clicking “Change Password,” an error message stating “Current password is incorrect” is displayed. We can observe this response in Burp Suite’s HTTP History, and notably, we are not logged out this time.
Right click and send this request to repeater.
In the Repeater tab, let’s change the current password to the correct password while leaving the new passwords mismatched. When we send this request, it returns an error stating that the “new passwords do not match” and notably, we are still logged in. This means there is no brute force protection mechanism applied here.
So we identified 2 scenarios in Case 3.
Scenario 1: Incorrect Current Password
If the current password is incorrect and the new passwords don’t match, the error message displayed is: “Current password is incorrect.”
Scenario 2: Correct Current Password
If the current password is correct but the new passwords don’t match, the error message displayed is: “New passwords do not match.”
These error messages help identify the specific issue with the password change attempt, allowing for precise troubleshooting. Given this functionality, we can attempt a brute force attack on the current password field without being logged out after each failed attempt. This allows us to repeatedly try different passwords until the correct one is found.
So let’s send this request to intruder. In intruder positions tab select Attack type to Sniper.
Change value of username to carlos.
Click on “Clear §” to remove all the automatic payload positions. Highlight the value of current-password.
Click on “Add §” to mark this value as a payload position. It will be surrounded by § symbols.
We have the password list on the lab page.
Navigate to the “Payloads” tab in Intruder. you can see the Payload tab in the intruder section as shown below.
In the “Payloads” section, make sure “Payload set 1” is selected, corresponding to the position you marked.
Under “Payload sets”, select “Simple list”.
Copy the passwords provided and click on paste in intruder’s Payload section to add list.
Now that we have set the payload click on “start attack” button.
Burp Suite will start sending requests with the corresponding payload defined in the list and display results in the Intruder tab.
Upon viewing the results we can differentiate unique requests based on length and we found a request with length, different than others.
Let’s render the response of this request, and we can see it says “New passwords do not match.” This indicates that the current password provided in this request was the correct password for Carlos.
Let’s log out from Wiener’s account and attempt to log in to Carlos’ account using the password we identified.
As soon as we click on login, we successfully access Carlos’ “My Account” page, and the lab is marked as solved.
Congratulations! The walkthrough of Twelfth authentication lab finishes here.
You can see walkthrough of Thirteenth lab by clicking the following link:
