GSB Bruteforce

Context

As part of my BTS SIO, we developed a website in PHP with the CodeIgniter framework: GSB.

We were then asked to test our site's security and fix the most well-known security vulnerabilities.

I tried to run brute-force attacks against my project using existing tools like Hydra, but because of the site's design, the MVC pattern and how the framework works, it's almost impossible to use Hydra to crack a user password.

Indeed, Hydra relies on the HTML content of the form's target page to know whether a login attempt succeeded, but my site relies on a pure PHP page (without a single line of HTML) to check whether credentials are valid.

I decided to build my own brute-force application that uses URL redirects and HTTP status codes to determine whether a login succeeded, which fits better with my site's design.

How it works

The source code is split into two parts. The first generates passwords following the password conventions used by the provided dataset, i.e. 5 characters that are either lowercase letters or digits. A few lines can be changed to use other lengths and character sets.

The second uses the curl API and its C library, libcurl, to send POST requests to the form passed to the program. It tests the password and checks the HTTP status codes as well as URL redirects. If it lands on the correct URL, it displays the username and password and ends the program.

If no password is found, the program indicates that too.

Testing the program

We assume the username is already known, since the dataset always follows the same convention (first letter of the first name, followed by the last name, unaccented and lowercase).

We start by targeting the URL where the form is located, then attempt to log in. We use the browser's developer tools to see the content of the request sent.

We now have the exact request sent by the form, along with the variable names. My GitHub project's source code already uses this request.

My program can use either URL redirects or HTTP status codes to determine whether the login succeeded. If we know the URL that logged-in users land on, we can use it directly. Otherwise, a few tests with the curl API are needed to figure out which HTTP code means the login failed, and then only display results when a different code is returned.

In this example, let's assume we already know the logged-in URL, which is the "selection" page. The program will test every possible password combination.

As we can see, a failed login returns the "index" URL, with an error GET parameter, along with an HTTP 200 status code. When the login succeeds, we land on the "selection" URL, with an HTTP 500 status code.

Therefore, regardless of which method described above is used, the password would have been found. Finally, the program displays the username and password.