Broken brute-force protection, multiple credentials per request

Abdullah Hamza
4 min readAug 3, 2024

--

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.

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.

Lab homepage

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”.

login using provided username

As soon as we click on Log in button it says Invalid username or password.

Error on log in

Let’s see the Log in POST request in burp HTTP history. The login POST request contains username and password.

Login POST request

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.

Login POST request in repeater

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.

Testing for account lock mechanism

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.

Testing for array of strings in password field

We are provided with the password list on lab page.

Password list provided 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.

Including provided passwords in 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.

Password match found in the array

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.

Session cookie replaced

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.

--

--

Abdullah Hamza
Abdullah Hamza

Written by Abdullah Hamza

Developer | CEH | Penetration Tester | Red Team

No responses yet