HTTP POST Login Form
In most internal and external assessments, we will face a web service.
Depending on the service,
we may not be able to interact with it until we log into it.
If this is our only vector and we’re unabl to use default credentials to log in,
we should consider using a dictionary attack to gain access.
Most web services come with a default user account, such as admin.
Using this known username for our dictionary attack
will dramatically increase our chances of success
and reduce the expected duration of our attack.
In this section, we’ll perform a dictionary attack
on the login form of the TinyFileManager application,
which is running on port 80 on the target web server.
Let’s browse to the login page.
After reading the application’s documentation,
we discover that TinyFileManager includes two default users:
admin and user.
After trying and failing to log in with the application’s default credentials,
we’ll attack the password of user with the rockyou wordlist.
Attacking an HTTP POST login form with Hydra
is not as straightforward as attacking SSH or RDP.
To begin we need to gather two different pieces of information.
The first is the POST data itself,
which contains the request body specifying the username and password.
Second, we must capture a failed login attempt
to help Hydra differentiate between a successful and a failed login.
We’ll use Burp to intercept a login attempt
so we can grab the request body in the POST data.
To do this, we’ll first start Burp and activate intercept.
Next, in our browser, we’ll set FoxyProxy to capture Burp traffic.
Then enter a username of user and any password into the login form.
The highlighted area marks the request body
we need to provide for Hydra in the POST request.
Next, we need to identify a failed login attempt.
The invalid credentials message informs us that our login failed.
We’ll provide this text to Hydra as a failed login identifier.
Now we can assemble the pieces to start our Hydra attack.
As before, we’ll specify -l for the user,
-P for the wordlist,
and the target IP without any protocol,
and a new http-post-form argument,
which accepts three colon-delimited fields.
The first field indicates the location of the login form.
In this demonstration,
the login form is located on the index.php web page.
The second field specifies the request body
used for providing a usernam and password to the login form,
which we retrieved with Burp.
Finally we must provide the failed login identifier,
also known as a condition string.
Before we provide the arguments to Hydra and launch the attack,
we should understand that the condition string
is searched for within the response of the web application
to determine if a login is successful or not.
To reduce false positives,
we should always try to avoid keywords such as password or username.
To do so, we can shorten the condition string appropriately.
After executing the command,
we’ll wait a few moments for Hydra to identify a valid set of credentials.
In this case, our dictionary attack was successful
and we identified a valid password for user.
Let’s try to log in to confirm the credentials.
We logged in successfully.
Nice!
As with any dictionary attack,
this generates a lot of noise and many events.
If installed, a Web Application Firewall would block this activity quickly.
Other brute force protection applications could also block this,
such as fail2ban,
which locks a user out after a set number of failed login attempts.
However, web services aren’t often afforded this type of protection,
making this is a highly effective vector against those targets.