Password-guessing attacks are one of the most popular aspects of penetration testing. Passwords come from a lot of places—you can guess them, you can find them lying around in files, and in some cases, you can obtain them from the operating system. Passwords obtained from the operating system are sometimes in the clear or are reversibly encrypted, and sometimes they are stored as a hash, often known as a password verifier. A hashing function is designed to take an input and convert it to an output in a non-reversible manner, so you will sometimes see password verifiers referred to as an OWF (one-way function).
Password hashes are typically attacked (or cracked) using a combination of dictionary attacks and brute-force methods. With a dictionary attack, the attacker obtains a large list of words and feeds the list and the password hashes to the cracking tool. A brute force attack in its simplest form iterates through all possible passwords using a specified character set. For example, aaa would be followed by aab, aac, and so on. Although password attacks seem simple, there can be more to them than is obvious at first.
Passwords are found in many places. Most likely, they will be associated with user accounts, either locally or collected into a domain. Passwords can also frequently be found in places like the following:
In batch files and scripts
On Web pages
In helpful applications and operating systems that offer to save passwords for you
In service accounts, and in DCOM objects configured to run as a particular user
Under users’ keyboards and on sticky notes on the monitor
In Microsoft Excel spreadsheets "hidden" on a share
In text files, such as AdminPasswords.txt, that are hidden deep inside a server the user hopes you’ll never get into
On the network, especially where services accepting clear-text passwords run
In files left during software installation
In Simple Network Management Protocol (SNMP) community strings
Associated with password-protected files
All the locations in the preceding list were used during actual penetration tests. One penetration tester who worked for a major auditing firm had a batch file that he ran on systems to collect all the file types he knew about that might contain passwords. It is a useful approach. Remember that automated tools don’t do a very good job of finding passwords hidden in odd places, so this batch file technique will often get you into systems even where routine network scans occur.
A brute force attack typically consists of two different approaches: the first approach is a dictionary attack, and the second approach is to simply try all possible passwords within a key space. These two approaches can be combined, either by appending all possible characters to a dictionary word or by making common substitutions, such as 1 for I, or 4 for a. Brute force attacks can be launched against both online systems and password hashes that you’ve obtained.
Performing these attacks seems simple, but there are some twists you need to take into account. Let’s also get an idea of the scale of the problem. In general, the number of possible passwords is given by:
Number of Passwords = (key space)length
Table 15-1 shows the number of passwords created for some common scenarios.
Table 15-1. Number of Possible Passwords for Common Scenarios
Key space | Possible characters | Length | Number of passwords |
|---|---|---|---|
Case-insensitive
| 26 | 7 | 8.03E+09 |
Case-sensitive alpha characters | 52 | 7 | 1.03E+12 |
Alphanumeric characters | 62 | 7 | 3.52E+12 |
US English keyboard characters | 94 | 7 | 6.48E+13 |
Case-insensitive
| 26 | 15 | 1.68E+21 |
As you can see in Table 15-1, a password containing only alphabetic characters that is 7 characters long will yield just over 8 billion possible passwords. Seems like a lot of passwords, until you consider that a modern system (as of 2004) can generate password hashes at around 10 million hashes per second. Now things really don’t look so good. A 7-character, lowercase alphabetic password can have all possible permutations tested in only 13 minutes. A 7-character, case-sensitive password containing any possible character present on the keyboard can be brute-force attacked in 75 days! Interestingly, testing the entire possible key space for a 15-character password consisting of only lowercase alphabetic characters takes about 2 billion years. The phrase use a really long pwd is actually much harder to brute-force attack than P9;s$∼!, even though the longer phrase is much easier to remember. You’ll get into this problem in more detail in the "Countermeasures" section.
Online password testing is the process of attempting to find passwords by attempting a logon. Any service that allows you to authenticate can be used. Online password testing (sometimes called password grinding) is much slower than offline testing—a typical password attempt rate might be on the order of 50 passwords a minute. As you might imagine, a true brute force attack takes a lot longer. Under these conditions, trying millions of passwords simply isn’t an option. A better approach is a dictionary attack. The following password types will get you into many networks:
Blank. Using no password is much too common an occurrence.
password as the password. This is the most common non-blank password, even in non-English speaking countries.
Password same as user name. These are usually all lowercase, though sometimes users use mixed case. You can also try this one backwards.
Password same as machine name. Try lowercase, uppercase, and mixed-case variations.
There are a number of issues to be concerned about with online password testing: locking out accounts, placing load on the system, and being detected. Account lockouts, especially permanent lockouts, can create a serious denial of service (DoS) condition. Most operating systems and network devices can be configured to lock out accounts based on a certain number of failed passwords, the length of time between failures, and the length of lockout. You can use certain strategies to determine whether lockouts are in place, but first, experiment. Before you crank up a tool that will grind away at the passwords for an entire domain, try your strategy on one user and see what happens. In some cases, you’ll be able to determine that you’re being locked out. Windows systems will tell you the lockout policy if you have user-level access.
If you are faced with lockouts, one strategy is to try a single password for all the users, then start the user list over again with the next password. However, a very large user database might keep you from trying passwords often enough to cause lockouts. If you’re checking a small user database, all you can do is try fewer passwords than will trigger a lockout, wait, and then try some more. Typically, you won’t find many passwords using brute force attacks. On most networks, you can get into plenty of systems using the very weak passwords listed earlier. One exception to this is when you find a password by other means and you want to discover where else it is used. For example, if you find one system for which the administrator password is Passw0rd!, you should check other systems for use of the same password. Frequently, checking other systems on the network for a discovered password is a productive approach.
System loading is another factor to consider when conducting online password testing. For example, you might think that one way to check lots of passwords is to attempt a different password for the same user on a large number of workstations joined in the same domain. That would be a clever approach, but if the domain controller isn’t robust enough to handle that high a load, you’ll create a denial of service condition. In general, slow and steady gets you there, fast and clever causes crashes. The same advice holds for checking passwords by trying multiple connections to the same system. Even if the system does hold up to the load, the system must use a significant portion of the processing power to handle your password guessing attempts. Although trying dozens of accounts at once against a big POP3 server with plenty of CPU and RAM might not cause an issue, doing the same thing against a network device or a telephony controller could cause serious disruptions.
Avoiding detection is another consideration with online password checking, and this will vary depending on the operating system (or device) and the configuration for that host. In many cases, you will want to be detected. At one point, Microsoft’s Corporate Security group gave tee shirts to users who were vigilant enough to check their logs and show that they’d caught Microsoft probing their systems. If you want to avoid detection, try to avoid extensive password checking against systems configured to log failures, and certainly avoid placing large loads on servers.
Offline password testing is sometimes known as cracking passwords and is named after "crack," which is a tool created by Alec Muffett to test passwords from UNIX systems’ password files. There are a number of these tools, so a feature comparison isn’t feasible here. Also, different operating systems produce different hashes and might require specific tools to crack the passwords. Here’s a list of some hash types you might find out there:
UNIX and Linux hashes. A variety of different hash algorithms are being used, and UNIX systems typically "salt" a password hash to cause precomputed tables of passwords and hashes not to be feasible. Also, on older UNIX systems, the password file was readable by everyone. If the hashes didn’t have a salt, users could simply compare the hashes to see if anyone else had the same password. Some UNIX systems limit password length to only 8 characters, though modern versions typically allow longer passwords.
Windows LM hashes. Older Windows systems supported only an LM (for the old LAN Manager product) hash that was created in the 1980s. This type of hash has two substantial weaknesses. The first is that the password length is limited to 14 characters, and these 14 characters are broken up into to independent 7-character chunks. To make matters worse, the password is case-insensitive, reducing the possible key space to 68 characters. At a rate of 10 million hashes per second, this can be tested in less than a week—far faster than most domains require password changes.
Windows NTLM hashes. Although this mechanism has been supported since Microsoft Windows NT 3.1 shipped in 1993, Microsoft was able to enforce only that a system use these hashes with Windows 2000 and later systems. NTLM hashes do not break up passwords into chunks, are case-sensitive, and can support very long passwords—up to 128 or 256 characters on Windows 2000 and later systems.
An offline password attack is used when you have managed to obtain password verifiers. On a Windows system, this typically means dumping the password hashes, and on a UNIX system, it means that you’ve obtained the password file. You then use a program to try large numbers of passwords. In this section, you’ll learn some approaches that might help you obtain passwords more efficiently. Many of these approaches are available in various cracking tools. This section addresses the following types of offline attacks:
Dictionary attacks
Variant dictionary attacks
Brute force attacks
As you learned at the beginning of the chapter, a dictionary attack is the simplest and easiest attack: you obtain a large list of words, and feed the list and the password hashes to your cracking tool. Numerous word lists are available; many of these are available from or are linked to http://wordlist.sourceforge.net. Many penetration testers typically use a fairly small list of about 50,000 English words, but if you have the time and patience, create as large a list as you can manage. You can also maintain lists of previously cracked passwords. It is quite common to find passwords that are either composed entirely of dictionary words or derived from dictionary words. In one comical instance, I found a coworker who was using Shub-Niggurath as a password—it turns out that he is an H. P. Lovecraft fan.
In a variant dictionary attack, you start with a dictionary word, then modify it. One approach is to append a certain number of characters from a specific character set. This method can be very effective because users often use phrases such as password1 or password! and think they are clever. Another approach that can sometimes be combined with the approach just described is to look for common substitutions. Password complexity rules often require various character sets, and users substitute 0 for o, 1 for i, 4 for a, and so on. If your password cracker doesn’t support all these variations, you can create your own tools to create a new dictionary file from ordinary words; many scripting and programming languages will do the job.
As you know, with a brute force attack, you simply iterate through a character set, trying all possible passwords. Most password cracking tools support user-defined character sets; you might first try either all alphabetic characters or all alphanumeric characters. This small character set can be checked very quickly, especially if you have LM hashes to crack. A quick system can whip through such a set in only two hours. You might find that the passwords gained will give you the access that you need, and you can stop with this.
If you have LM hashes to crack, you will often find that you have the first 7 characters of the password but not the remaining characters. Users tend to place the characters needed to meet password complexity rules on the end of the password, so once you take a pass through with a reduced character set, you can set it to use the entire character set and test only up to around 5 or 6 characters—at this point, most of your passwords are cracked. Next, remove from the file the users whose passwords you’ve cracked, and try increasing the key space. For example, add the SHIFT+keyboard number characters such as !@#$ (SHIFT+!, SHIFT+@, and so on). One approach is to order the characters by those most often used; it might speed up the process a little.
If you are dealing with Windows systems and find that the LM hash is blank but the NTLM hash is not, the password is likely longer than 14 characters. I’ve never been successful at conducting brute-force attacks on passwords for that long, even with reduced key spaces.
The main countermeasures to thwarting password-cracking attacks are complex passwords, user education, smart cards, and lockouts. Complex passwords fall to a pure dictionary attack very rarely, and even then only when specialized dictionaries are used. A complex password uses characters from every available character set. Most cracking tools break up the characters used into uppercase and lowercase alphabetic and numeric characters, top row special characters, and others. A password that uses all four character sets will be difficult to crack.
Tip
Requiring complex passwords is an easy way to improve your network’s security, and even though measures like smart cards are stronger, requiring complex passwords is much less work to implement.
With commonly used minimum password lengths, a successful attack is always just a matter of time. If your password hashes are stolen, assume that all the passwords are compromised. Even so, if you can’t stop an attacker, buying time always helps. The more time elapsed between the initial compromise and the point at which the attacker is able to get further into the network, the better your chances of noticing something and taking corrective action.
User education goes a long way toward minimizing password-guessing attacks as well. If you have Windows 2000 or later domain controllers and Windows 2000 or later client, passwords longer than 14 characters can be used. This prevents the LM hashes from being created, and longer passwords yield a larger total search space more effectively than a larger character set. I personally find phrasing like Gee, will I ever finish this book? easier to remember than G#tilv;!. Getting users to think pass-phrase instead of password can help.
More Info
One very good reference on passwords is the "What Administrators Should Know About Passwords" document at http://www.microsoft.com/technet/security/readiness/content/documents/password_tips_for_administrators.doc.
The best approach to stopping password-guessing attacks is to get away from passwords entirely by using smart cards. Although smart cards can’t be used under all circumstances, they do get you out of the user-defined password business. Smart cards have the additional advantage of requiring the user to present something tangible they have in their possession, which adds another factor to the authentication sequence. Microsoft requires smart cards to access the network remotely in case a user’s password is stolen.
Account lockouts can turn password guessing attacks into denial of service attacks. Lockouts need to be used with care for this reason. In some cases lockouts are warranted, for example, when you’re dealing with a high-value asset as you would with online banking websites. Passwords are typically limited to short alphanumeric sequences, and most users will choose weak passwords, so setting lockouts makes sense to mitigate these limitations. There are several reasons why you should avoid using lockouts on internal networks. First, if an account is used to run a service and the password isn’t changed on all the accounts, a reboot of several systems at once can be enough to lock out the service account. Another reason to set the threshold higher than you might think at first is that a number of conditions exist where one stale password can actually trigger two logon attempts. If you do choose to use lockouts, give them a fairly high lockout count and a short lockout period. Long-term or permanent lockouts can easily be used by an attacker to cause serious problems.
Passwords often lurk hidden in the clear, or the attacker can obtain them using some level of subterfuge. Because there are a variety of ways to obtain passwords, you should use different approaches to find them. Remember that nearly all users will reuse passwords, and a password that restricts something as minor as spreadsheet formulas might also be chosen for more important accounts. Operational groups sometimes institutionalize password reuse. There have been cases in which the same password was used on as many as six different administrator-level accounts.
You can often find passwords lying around in some interesting places, one of the more common being in batch files or scripts. If you have access to a share or the entire file system, search for these files and look through them manually for embedded passwords. This tends to be tedious work, but it pays off almost all the time.
Despite many warnings to the contrary, users all too often embed passwords in the website source, especially to obtain access to databases. In many cases, you’ll find that the database user has a high level of access to the database, and you can leverage that access to take complete control of the database server. Be sure to try the same password elsewhere because there’s a good chance it has been reused somewhere else.
Tip
Users often share out the root of Web servers, especially internally. Always investigate a share that contains the source to a website.
Another place to look for passwords is inside files. I’ve found files full of passwords more than once, and they were usually conveniently labeled with descriptive names such as "UserPasswords.txt." You can also leverage user-friendly features in the operating system to help you. If you have administrative access to a system either locally or via terminal services, open Explorer and ask it to search for things like "password."
Passwords also sometimes show up inside leftover setup files. Microsoft has shipped more than one security bulletin because of this type of mistake. It’s been a while since any bulletins were issued regarding this problem, so it might be rare, but you should still pay attention to it.
Encrypted passwords can be found in several places as well. One of the more well-known is the LsaPrivateData, which can be accessed with LsaDump2 (http://razor.bindview.com). Any user account running as a service, or a DCOM object running as a user, will have a password stored in the LSA private data. You’ll quickly find that properly managing service accounts is one of your highest priorities.
Another location to find encrypted passwords is the protected data store for individual users. Applications that offer to store passwords frequently utilize this store. There are a number of available tools to access the protected data store.
Many applications such as third-party FTP clients offer to store passwords. E-mail clients also offer to store POP3 passwords. Obtaining the clear text sometimes take a little more work, but it isn’t usually very difficult; you just point the client application at a system you control, sniff the network traffic while running the client application, and presto! Passwords are in the clear.
More Info
For more information about network sniffing attacks, see Chapter 19.
A large number of applications that create documents allow you to password-protect documents, portions of documents, and items such as ZIP archives. If a user has password-protected one of these files, brute-force tools exist to crack the passwords, and there is a good chance that the same password has been used elsewhere.
Depending on what applications are running on the network, you can sometimes install a network sniffer on a system and gather passwords. For example, SNMP community strings are fairly easily decoded. Telnet and FTP servers accept passwords in the clear. Back in the bad old days, it was common for networks to be running on hubs, which meant one system got the traffic for most (or all) the local subnets. However, switches can sometimes be tricked into sending you someone else’s traffic. Although this issue is worth noting, rarely will you have to go to that much effort to get into systems.
You might want to avoid the software keystroke logger approach, which involves installing a potentially unstable driver into the operating system. Many loggers leave files lying around with the keystrokes in them, and you might not be able to get back into the system later. If you can’t clean up after yourself, you run the risk of leaving sensitive data lying around. Another risk is that the user might be typing in sensitive data such as an employee review. However, penetration testers have been known to use this approach very successfully, and it can sometimes be your last resort. You can often accomplish the same goal by installing a Trojan into the logon sequence or startup folder, and this approach doesn’t potentially leave sensitive data lying around.
Password logging applications exist that target only logon sequences and password dialogs. If you have an application running on a desktop, it is possible to intercept all the keystrokes going to all the windows. You can install an application that selectively logs only keystrokes sent to password dialogs. There have also been several "password filter" applications written that log passwords submitted upon local logons. As usual, test these on your systems before trying them on systems you’ve compromised, because many of the tools available are not of high quality, or they break in various ways when run on a version of the operating system that is different from the one they were tested on.
Unfortunately, password disclosure issues are largely a matter of education and can be difficult to address, which is one of the reasons that they are almost always a productive area for a penetration tester. Following are some of the strategies you can employ to help alleviate the problem of password disclosure:
Batch files and scripts. Create a policy stating that these files cannot contain actual passwords. Require the files to prompt for passwords. Audit these files for compliance. If you have time, create scripts that will copy these files from accessible network shares, and then try looking though them. Findstr, grep, and Perl are all useful tools when tackling this problem, though you will find that a notepad, hard work, and your brain are the only really reliable tools because users come up with a wide variety of formats.
Web pages. Search the source for websites to look for connection strings. In particular, check whether the source for the website is shared out and whether the share has the appropriate permissions. When you find embedded connection strings, see whether you can get the website developer to switch to a better method for storing secrets like passwords. You’ll find some techniques for this in Writing Secure Code, Second Edition (Microsoft Press, 2003). The best approach is to switch the SQL Server to native mode and use Windows accounts, but if you’re dealing with a cross-platform solution, that solution might not be available. If there is no domain controller, consider using two local accounts with the same user name and synchronized passwords.
Service accounts. Be careful with how service accounts are used, and most especially regarding where they are used. A service account running with elevated domain privileges needs to be secured as carefully as a domain controller.
Applications that store passwords. All you can do here is try to educate users and disable this feature when possible.
Services accepting clear-text passwords. Eliminate these from your network to the extent possible. Replace Telnet with either versions of Telnet that accept NTLM authentication, Secure Shell (SSH), or Terminal Services.