Active Brute-Force Tools

---

Active tools tend to be the last resort for password guessing. They generate a lot of noise on the network and against the victim (although they can go unnoticed for long periods of time). The toughest part of starting an active attack is obtaining a valid username on the victim system. Chapter 7 provides more information for techniques to gather usernames.

Another useful step is to try to discover the lockout threshold before launching an attack. If the lockout period on an account lasts for 30 minutes after it receives five invalid passwords, you don’t want to waste 29 minutes and 30 seconds of guesses that can never succeed.

THC-Hydra

Hydra easily surpasses the majority of brute-force tools available on the Internet for two reasons: It is fast and it can target authentication mechanisms for more than a dozen protocols. The fact that it is open source (under the GPL) and part of the Nessus assessment tool also adds to Hydra’s merits.

Implementation

Hydra compiles on BSD and Linux systems without problem; the Cygwin environment and Mac OS X present more difficult challenges against which the current version (2.4) cannot compile. Otherwise, go through the usual ./configure; make; make install. Once you have successfully compiled it, check out the command-line arguments:

Hydra v2.4 (c) 2003 by van Hauser / THC <[e-mail]> Syntax: hydra [[[-l LOGIN|-L FILE] [-p PASS|-P FILE]] | [-C FILE]] [-o FILE]   [-t TASKS] [-g TASKS] [-w TIME] [-f] [-e ns] [-s PORT] [-S] server   service [OPT]     Options:   -S        connect via SSL   -s PORT   if the service is on a different default port, define it here   -l LOGIN  or -L FILE login with LOGIN name, or load several logins from FILE   -p PASS   or -P FILE try password PASS, or load several passwords from FILE   -e ns     additional checks, "n" for null password, "s" try login as pass   -C FILE   colon separated "login:pass" format, instead of -L/-P option   -o FILE   write found login/password pairs to FILE instead of stdout   -f        exit after the first found login/password pair   -t TASKS  run TASKS number of connects in parallel (default: 4)   -g TASKS  start TASKS number per second until -t TASKS are reached   -w TIME   in seconds, defines the max wait reply time (default: 30)   server    the target server   service   the service to crack   OPT       some service modules need additional input, put it here

The target is defined by the server and service arguments. The type of service can be any one of the following applications. Note that for several of the services, a port for SSL access has already been defined. The first number in the parentheses is the service’s default port; the second number is the service’s port over SSL. Make sure to use the –s option if the target service is listening on a different port. These are the current services that Hydra recognizes:

• telnet (23, 992)   Remote command shell.

• ftp (21, 990)   File transfer.

• pop3 (110, 995)   E-mail access.

• imap (143, 993)   E-mail access.

• smb (139, 139)   Windows SMB services such as file shares and IPC$ access.

• http (80, 443)   Web services.

• https (n/a, 443)   Web services over SSL.

• cisco (23)   Telnet prompt specific to Cisco devices when only a password is requested.

• cisco-enable (23)   Entering the enable, or super-user, mode on a Cisco device. You must already know the initial login password and supply it with the –m option and without the –l or –L option (there is no prompt for the username).

  hydra –m letmein –P password.lst 10.0.10.254 cisco-enable

• ldap (389, 636)   Lightweight Directory Access Protocol, often used for single sign-on.

• mysql (3306, 3306)   Database.

• nntp (119, 563)   USENET news access.

• vnc (5900, 5901)   Remote administration for GUI environments.

• rexec (512, 512)   Generic Unix service for remote execution. Access to this service is not logged by default on some systems.

• socks5 (1080, 1080)   Proxy.

• icq (4000, n/a)   Chat software. ICQ is carried over UDP, which means it cannot be used over SSL.

• pcnfs (0, n/a)   Used for printing files across a network. The default port varies among distributions and individual servers, so it must always be explicitly set with the –s option. This service also uses UDP, which means that SSL cannot be applied.

Running hydra is simple. The biggest problem you may encounter is the choice of username/password combinations. Here is one example of targeting a Windows SMB service. If port 139 or 445 is open on the target server and an error occurs, then the Windows Server service might not be started—the brute-force attack will not work.

[mike@corrino]$ hydra –L user.lst –P password.lst 10.0.1.4 smb Reduced number of tasks to 1 (smb does not like parallel connections) Hydra v2.4 (c) 2003 by van Hauser / THC - use allowed only for legal purposes. Hydra is starting! [parallel tasks: 1, login tries: 42 (l:6/p:7)] [139][smb] login: administrator   password: changeme% Hydra finished.

Hydra reports the total number of combinations that it will try (usually the number of unique usernames multiplied by the number of unique passwords) and how many parallel tasks are running.

Tip 

You will never be able to try more than one parallel task against an smb service, even if you use the –t option to increase the number. For whatever reason, parallel logins against SMB produce too many false negatives. The default value for –t is 4, which is also recommended for Cisco devices and Virtual Network Computing (VNC) servers. The maximum is 255, but that is not necessarily the optimum or most accurate setting to use.

If you really do want to have an optimum test, as opposed to an exhaustive test, you may want to consider the –C option instead of supplying a file each for –L (users) and –P (passwords). The –C option takes a single file as its argument. This file contains username and password combinations separated by a colon (:). This is often a more efficient method for testing accounts because you can populate the file with known username/password combinations, which reduces the number of unnecessary attempts when a username does not exist. This is more useful for situations in which you wish to test only for default and the most common passwords.

Do not forget to use the –e option when auditing your network’s services. The –e option turns on testing for the special case of no password (-e n) or a password equal to the username (-e s).

Case Study: Checking Password Policy

A tool such as hydra is used for two major reasons: either during a network penetration test or during a system audit. The two activities sound similar in execution, but they differ in their goals. Consider Iain, a system administrator in the Internal Audit department. The IA folks do not administer systems; they verify that systems have been built to corporate security policy. In other words, Iain's responsibilities include testing network accounts for passwords that do not meet the company's established policy.

The policy requires that all accounts be password protected (no NULL passwords allowed), the password must be nontrivial (open to interpretation, but at the very least that means the password should not equal the username), contain at least one digit and one punctuation character (letters only are not permitted), and must be at least eight characters long. For some Windows and Unix systems, it is possible to enforce these rules when users go through the password change process. On other systems, such as Cisco devices, it is not possible.

Iain faces the challenge of finding weak passwords in one of the following scenarios:

• A system does not have a method for enforcing good password choices. Users must be trusted to choose strong passwords.

• A system has a method for enforcing good password choices, but it has been misconfigured. Users are still required by policy to choose strong passwords, but this is not enforced.

• A system has a method for enforcing good password choices, but users can easily satisfy the requirements with trivial passwords (such as password99!, pa$$w0rd, or adm1n1str@t0r).

Now, Iain has already identified some network services that could prove to be fruitful targets. However, it would not be a good idea simply to obtain the list of users, grab a 200,000-word dictionary, and start hydra (or several hydras since there's a lot of work to do). Instead, he crafts a dictionary with words that do not meet policy, plus some words that do meet policy but that are based on number/vowel substitution or similar tricks. In fact, John the Ripper (mentioned previously in this chapter) provides the perfect method for creating password lists based on length and content. Then, just as a test, he creates an oldwords.txt file that contains the root and administrator passwords used before the last required password change. The oldwords.txt file follows the username:password syntax. For example,

root:web34addmin!
Administrator:thiS1&thaT1
oracle:2bdb|!2bdb

Lets recap for a moment. Iain has created three files (and will have a fourth and fifth option):

• Users.txt   A list of every (known) username across systems.

• Passwords.txt   A list of common one- to seven-letter combinations, plus some selected 8-plus letter combinations with number/vowel substitution. The majority of this file can be pulled from dictionaries available on the Internet, the default password.lst that comes with John the Ripper, or created by John the Ripper. The list contains no more than 1000 combinations to limit the number of failed logins that will be logged by the servers.

• Oldwords.txt   A list of account and password combinations that should have been changed in the last 90 days. Of course, this file must be kept secure.

• NULL passwords   Use the -e n option for hydra to check all accounts for a blank password.

• “Same” passwords   Use the -e s option for hydra to check all accounts for passwords that equal the username.

So far, it sounds like quite a bit of work has been done without Iain even worrying about whether or not hydra will compile. There's a good reason for this: Iain has set up a method for testing his company's password policy. At this point, he is ready to launch hydra against the selected services. (After he has once again verified that accounts will not be locked by failed login attempts.) Then, any positive matches can be brought to the attention of network and system administrators because the account has failed to meet policy requirements.

Just for a second, imagine that Iain had driven into the password audit without forethought; he grabs a random 10,000-word dictionary and launches hydra over a three-day weekend against 200 accounts. If he's lucky, it might even finish. If he's really lucky, no servers will have crashed because they ran out of disk space logging all of the failed attempts. Finally, what if a relatively strong password, such as ou@te1tw2 or -#*crAft0 shows up in the results simply because it was present in the dictionary? He would have a hard time convincing the user that he or she failed an audit when in reality the user had chosen a strong password.

On the other hand, blind luck and a big dictionary are just the right ingredients for a successful penetration test. Thus, we come to the point where password auditing with hydra ends and its use as a penetration-testing tool begins.

---