In the last article in this series we looked at how easy it is to carry out a brute force attack on a password file containing the hashes of users’ passwords. By using John the Ripper to systematically try out every password from a word list, and then every possible permutation of letters, numbers and other characters for passwords of increasing length, you are bound to find any passwords which are common English words or which are reasonably short.
But what about a situation where you don’t have access to the file containing hashed passwords? This makes things considerably harder, because instead of having the luxury of taking away the file and subjecting it to password attacks at your leisure, you have to perform an online password attack. This means that every password guess you make has to be sent over the network to the appropriate server (along with a username in most cases.) You then have to wait for a response from the server to see if your guess was successful. If it wasn’t (which will be almost all of the time) then you’ll have to repeat the process, sending in another guess and waiting for the response.
It’s often possible to send in multiple guesses concurrently, but even so online password attacks are very, very slow, compared to offline attacks, which are only speed-limited by the power of the computer you are using.
Online attacks are more than just slow. There are many security hurdles to overcome. Many servers have security features which limit the number of failed password attempts that are allowed before the account is suspended, your IP address is blocked or the period before a new login attempt can be made is extended. They should also log where failed attempts are coming from and alert administrators.
This makes it hard for a hacker to carry out an online attack on your systems. Which is good. The question is how hard? Do the systems work? Would you know if someone was carrying out an online attack, and what would you do about it?
The best way to answer these questions is to carry out an online attack yourself, and see how far you get.
The open-source tool you’ll need for this is called Hydra, available from http://freeworld.thc.org/thc-hydra/.
It’s available for Windows, handheld ARM-based devices and Palm PDAs precompiled, or as source code which you can compile for MacOS X or your favorite Linux distribution. There’s even a GUI for the Linux version.
After downloading the Linux version and compiling (following the instructions included in the README.txt file), you can launch the GUI version by typing
from the Hydra directory.
The Hydra GUI will start, showing the Target tab (see Figure 1). The first thing to choose is what you want to test: Hydra can handle abut forty common protocols, including Pop3, telnet, ftp, VNC, SMTP, Cisco auth. You can select the protocol you want from the Protocol dropdown box, and choose a target either the name or IP address of a single server, or a text file with a list of them.
On the Passwords tab, you can then choose to test a single username in this case hydratest, and specify a Password list that you want to test. (See Figure 2.)
The Tuning tab is used for selecting the number of login attempts that are submitted simultaneously, and this number can be quite critical. Too high and the chances of being detected or locked out of the system are much higher, but too low and it could take days to work through your password list.
Once you are ready to launch the attack, click the Start tab, and click Start. In the example illustrated in figure 3, the correct password was found in about three seconds.
In the next example, the password was very far down a very long password list. Look what happens: the POP3 server has got fed up with too many failed login attempts and appears to have locked us out of the system. It may be a few minutes or hours before another attempt can be made. If you find you can work through a long list of passwords fairly quickly then it is well worth reconfiguring the security settings on your server to block access after fewer failed login attempts: legitimate users may misspell their passwords a couple of times, but there is no reason why anyone should be entering their password incorrectly ten times on the trot. (See Figure 4.)
Because online attacks are susceptible to this kind of lockout, hackers try to make their password lists as targeted as possible. If they can find out any information about the owner of a given username (from Web sites such as FaceBook for example) such as a pet’s name, it’s likely that that will be included in the list. A tool that they may also use is Wyd, a Perl script which is available from http://www.remote-exploit.org/codes_wyd.html
Give Wyd the address of a particular Web site and the tool will extract “useful” words that appear on it to add to a password list. The idea is that for reasons of corporate loyalty or whatever, many people use passwords connected to their work, projects they are working on, places they do business, or other bits of information found on the Web site. It’s certainly worth using Wyd to create a corporate password list for your organization from your corporate Web site, to use with Hydra to see if anyone is using an easily guessable password.
Once again, checking your servers’ security is a matter of putting yourself in the position of a genuine hacker. Many will use bots to carry out online attacks – perhaps on your SMTP server to see if they can guess a password and use your server to send out spam. If you use Hydra to successfully guess a password or two then so can the bots. An hour or so finding out what Hydra can come up with is definitely time well spent.