Broken brute-force protection, multiple credentials per request
To access the lab visit the following link:
This lab is vulnerable due to a logic flaw in its brute-force protection. To solve the lab, brute-force Carlos’s password, then access his account page.
- 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 the username provided and some random password to capture the login request using burp. In this way we can see the login functionality of the application. In this case I used the password “12345”.
As soon as we click on Log in
button it says Invalid username or password
.
Let’s see the Log in
POST request in burp HTTP history. The login POST request contains username and password.
Right click on this request and select Send to Repeater
. In the Repeater tab, we will send the same request multiple times to test if the account lock mechanism is triggered. Each time we send the request, we receive a response with status code 200 OK
.
Upon Rendering
the response of request, we observe that it consistently returns the error message Invalid username or password
. This indicates that the application does not lock the account after multiple failed login attempts.
In the login request we can see that the provided data structure for username and password appears to be a JSON object, which is commonly used in web applications for data exchange. Let’s Provide the array of strings in password field to test if the web application accepts an array of password.
When we send request with array of strings in password field, we still receive a response with status code 200 OK
. The array of passwords suggests that the web application can handle multiple password attempts in one go.
We are provided with the password list on lab page.
Let’s copy these passwords and include them in the request as an array of strings. Click on send button to send the request.
Upon sending the request, we received the response 302 Found
. This response suggests that the application accepted the array of passwords, found a matching password, and successfully logged in the user “carlos.” The redirection to the account page and the setting of a session cookie confirm a successful authentication.
Let’s copy this Session Cookie
. Go to the login page, right-click, and select the Inspect option. Navigate to the Application tab, and under the Cookies section, replace the existing Session Cookie
with the Session Cookie
for Carlos that we received in the response. Then, click on the “My Account” option on the login page to reload the page using Carlos’s session cookie.
Once the page reloads, we can see that the username has changed to Carlos, indicating that we have successfully accessed Carlos’s “My Account” page. Additionally, the lab is marked as solved in the browser.
Congratulations! The walkthrough of Thirteenth authentication lab finishes here.