Chapter 4: Preventing Password Crackers


Windows computers and networks can easily be made very resistant to password cracking attacks. Network administrators can implement a handful of automated security settings and prevent the success of every password cracking tool today. This chapter begins with a discussion of Windows password authentication, reveals how passwords are attacked, and explains how to prevent successful password attacks.

Windows Password Authentication

As Chapter 3 covered, there are four stages of access control: identification, authentication, authorization, and accounting/auditing. When logging into Windows, the security principal (user or computer) provides a unique logon name and password (ignoring other forms of authentication credentials for the purposes of this discussion). The password is a series of characters, numbers, or symbols that should only be known to the entity using the password and the authentication service. When the inputted password is confirmed by the authentication process, it confirms the identity of the security principal attached to a particular Windows session, and the security principal is considered authenticated.

How big can a Windows logon password be? Windows logon passwords can be quite big. A Windows 2000 and later logon password can be up to 127 characters long and contain 65,535 different characters. The character set includes every possible character and symbol that Windows supports. If people actually used all the possible symbols and made very long passwords, it would result in over 4.92 × 10611 possible unique passwords. That's basically the number 49 followed by 610 zeros. It's huge! If it were a crypt key, it would be 2,032 bits of encryption. The young kid in me wants to say something made up like gazillion million billions.

Note 

NT 4.0 passwords could only be made up of 142 different characters and the maximum password length was either 14 or 127 (many sources incorrectly say 128) depending on the tool used. If the password were set in User Manager or using the Net Use command, password length was restricted to 14, but the user could type in up to a 127-character password when changing in the normal password change GUI (i.e., Ctrl-Alt-Del). As discussed below, however, all NT 4.0 passwords were truncated to a maximum of 14 characters internally.

If Windows users actually used long and truly varying passwords, it would defeat every password guesser and cracker today and in the future. If the attacker had a million computers making a million guesses a second, it would take millions of years to find a correct password. There is not even enough hard drive space in the world, all combined, to store all the possible password combinations that result from 65,535 characters in passwords up to 127 characters long. Of course, most Windows users don't use very long and complex passwords.

Unicode Passwords

Many people think the only characters they can use in a password are the ones located on the keyboard, which totals 94 different symbols if you include both uppercase and lowercase letters. However, using either of the Alt keys along with a number from the numeric keypad (it does not work using the regular numbers above the letter keys) or other programmatic means will result in one of the 65,536 different Unicode symbols. And Unicode symbols can be used in Windows logon passwords.

Note 

Not all 65,536 Unicode characters can be created from the keyboard keys alone. Using the Alt key combinations results in a repeating pattern of a much smaller set of Unicode characters. In order to access all 65,536 Unicode characters, GUI-based and programmatic means must be used.

The Unicode character set is a way for operating systems to represent a wide variety of languages and symbols. Behind the scenes, underlying all the symbols and characters we see, is a numeric code. If the user or computer changes fonts, characters sets, or languages, the Unicode number will ensure that the new format representation is accurately reflected in its new form. For instance, a Unicode hexadecimal number 0101 (i.e., decimal 65) will result in a lowercase Latin letter e. Whenever the user or computer uses an e in Windows, behind the scenes it is stored as hexadecimal character 0101. If the computer or user changes the font, character set, or language, the e will be translated into whatever other representation it takes in the new format.

You can view many of the possible Unicode characters using the Character Map applet (click the Start button and choose All Programs ð Accessories ð System Tools ð Character Map. As Figure 4-1 shows, the Latin lowercase e is represented by hexadecimal code U+0065. To type in any Unicode symbol into a document or as a password, the user must hold down one of the Alt keys and then select the necessary decimal digits from the numeric keypad. If using the Character Map, the user might first need to convert between the hexadecimal number displayed in the Character Map and the decimal number needed to be typed in, although Character Map often displays the decimal equivalent in the bottom right corner of the dialog box. For a Latin lowercase e, the user would type in Alt-0101. Of course, for the lowercase letter e, the user would be better off typing in the e off the regular letter keys.

image from book
Figure 4-1

Passwords containing Unicode symbols are especially beneficial when the user uses a symbol that isn't already represented by one of the normal 94 keyboard characters that a password guesser or cracker would normally use. For example, the Unicode symbol ω (lowercase Greek letter Omega) can be typed in using Alt+911 (decimal 911was converted from hexadecimal number 038F using the Windows calculator). I've never seen a password cracker use this symbol in an attack. And because typing in an unusual Unicode character requires holding down the Alt key plus up to four other number keys, the idea is that it makes it more difficult for people shoulder surfing for passwords to easily view the password.

There are caveats if you choose to use a Unicode symbol in your password. First, not all systems and software support Unicode characters. Avoid using Unicode symbols on accounts that interface with older operating systems (e.g., MS-DOS, Windows 3.11, etc.), most web sites, and lots of other software that only expect the normal 94 keyboard characters. For instance, the Recovery Console feature in Windows 2000 and later does not allow Unicode symbols in the Administrator's password. Second, if you want to make the password more complex, don't use a Unicode symbol that is represented on the normal keyboard keys. That would just complicate the entering of the password with no increase in password complexity. Lastly, some Unicode characters are converted by Windows into normal alphabetic characters. For a complete list of Unicode characters to avoid, view the document located at www.microsoft.com/technet/security/smallbusiness/prodtech/windowsxp/select_sec_passwords.mspx.

The reality is that unless forced, most people use alphabetic characters only, and usually their password is a dictionary-based word (i.e., word, date, or name). So a password hacker doesn't have to cycle through a gazillion million billion potential passwords (the number of total possible password combinations if using all possible characters and combinations is known as the key space). Instead, the password key space used by a password guesser or cracker is at most a few hundred thousand words. In many cases, passwords can be guessed within a few hundred tries. A weak password will defeat strong security and allow any operating system to fall prey to a hacker. This fact is not lost on Microsoft.

Password Complexity

Starting with Windows XP Pro, increased password complexity is enabled by default. Windows password complexity requires that a user's password be a minimum of six characters long and contain characters from three of the five character types:

  • Uppercase letters: A, B, CZ

  • Lowercase letters: a, b, cz

  • Numerals: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9

  • Symbols (all keyboard characters not defined as letters or numerals): ` ~ ! @ # $ % ^ & * ( ) _ + - = { } | [ ] \ : "; ' < > ? , . /

  • Unicode characters

The password cannot be the user's logon name or contain part of the user's name. It cannot be identical to one used before if tracked by Windows (i.e., Password history). These password complexity rules are enforced on local and domain logins. In a domain, the password policy rules are identical on all computers attached to the domain (although this might change in future versions of Windows). So, when password complexity is enabled or disabled, it is enabled or disabled across the domain and applies to all computers at once.

Windows NT has the ability to require complex domain passwords using an additional file called passfilt.dll (http://support.microsoft.com/default.aspx?scid=kb;en-us;Q161990). In Windows 2000 and later, password complexity can be enabled or disabled using a registry edit change, Local Security Policy, or a group policy object. The latter option is covered in more detail below and in Chapter 14. Local password complexity can be controlled by editing the Local Security Policy. To do so, click the Start button, select Run, type in Gpedit.msc and press Enter. This brings up the Local Computer Policy object. Then browse to Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy (see Figure 4-2).

image from book
Figure 4-2

Password complexity is enforced when passwords are created, modified, or reset using the normal Windows tools. There are a few instances when password complexity does not apply:

  • When typing in the Directory Services Restore Mode Administrator's password during a domain controller promotion

  • Importing user accounts outside the normal GUIs

  • When creating or modifying the password outside the normal GUI or using third-party tools

Are Complex Passwords Complex?

Even when password complexity is enabled, most user passwords aren't overly complex. Though they can theoretical use 65,535 different symbols, most users limit themselves to the basic alphanumeric character set of 62 characters:

 abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890 

And if strong password policies aren't enforced, most users pick passwords six characters long or less, and they choose an alphabetic character password that spells a word that could be found in the dictionary.

Many studies (for example, Microsoft's "The Great Password Debates: Pass Phrases vs. Passwords" at www.microsoft.com/technet/security/secnews/articles/itproviewpoint100504.mspx) have shown that even complex passwords can be guessed because most users employ predictable complex password patterns. Even when Windows password complexity is enforced, users select the basic alphanumeric list above, plus a few symbols. Many alphabetic characters aren't frequently used (e.g., q, x, and z). When users add a number to their password, they most often place it at the end and use the numbers 1 or 2. When special symbols (e.g., !@#$%^&*( )?) are used in the password, the most commonly used symbols are !,@, $, and #. The @ symbol is most often used in place of the letter a, and $ is most often used at the end of passwords or in place of the letter s or the number 5. The ! and # symbols are most often used at the end of a password. And still the password contains a complete English dictionary word (on English-speaking user's computers, of course). Thus, a password cracker hoping to crack most Windows passwords need only use a modified character set (this is known as hybrid dictionary attack):

 abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890!@#$%^&*()?<> 

And instead of guessing every possible combination from these 75 different characters, they can start with dictionary words. Many automated password cracking tools come with a similar character set installed (covered more below) and crackers can pick and choose between varying character sets and load different dictionaries for the tool to use. Many password cracking tools allow hybrid password guessing whereby the various non-alphabetic symbols and numbers are tried in the common locations discussed above.

Using a Strong Password

A truly strong password has sufficient length (15 character minimum), contains one or more special characters (preferably not the common ones and not used in the common places), and does not contain a complete dictionary word. A user's password should not be easily guessable. For men, this means the password should not be something associated with their hobby or favorite sport. That CEOs use a lot of golf terminology in their passwords is not a big secret. For women, the most common passwords are derived from loved ones, often pictured in photos close to their computer. It's a sexist statement to make, but accurate, nonetheless. Tape backup service accounts often have the password "tape," "backup," or "tapebackup." Other common passwords include the word "password," "admin," "secret," "12345," or something like that.

Many common password lists are available on the Internet, sharing common passwords in use on most networks. The biggest list contains about 80 different passwords. The list is so small because many pass-words are very common. The odds are good that if the password list is tried against all users on the network, one of them will strike. Popular computer worms (see http://securityresponse.symantec.com/avcenter/venc/data/w32.gaobot.alv.html for an example) often contain password-guessing routines. Their internal list contains maybe a few dozen passwords. How well do the worms' lists work? The worms successfully infect hundreds of thousands of machines.

Another common password problem is leaving the default password the system or device uses as assigned by its manufacturer. Although Windows doesn't use a default password, many software programs, other operating systems, and network devices do. Default password lists can be found all over the Internet. Example lists are located at www.phenoelit.de/dpl/dpl.html, www.cirt.net/cgi-bin/passwd.pl, and www.pentest.co.uk/documents/default-user.htm. Again, it is almost rare to find a network that hasn't left at least one default password intact.

To recap, a strong password is sufficiently long in length (we will talk more about this later), contains one or more non-alphabetic characters (preferably not in the usual places), is not a complete dictionary word, and is not readily guessable.

Windows Password Hashes

In most of today's operating system authentication systems, passwords are not stored in plaintext or transmitted across the network in plaintext. Plaintext passwords are too easy for a hacker to find and too easy for a network sniffer to capture. Instead, passwords are usually stored in an obscured form. Windows logon passwords are stored in either the security accounts management (SAM) database or the Active Directory database (Ntds.dit) in an encrypted hashed form.

A hash algorithm takes a given input and mathematically produces an output that is unique for the given input. A good hashing algorithm has several properties, including the following:

  • The same input will always produce the same hashed output (called a hash).

  • Different input should always result in a different hashed output.

  • No two different inputs will ever result in the same hashed output. If two different inputs create an identical output, this is called a collision, and if these can be reliably produced non-trivially, it marks the hash algorithm as weak.

  • It should be non-trivial to convert any given hash output to its original input.

Hashes are used in all sorts of cryptographic processes beyond storing passwords securely, including being used in authentication and verification routines. Figure 4-3 shows many common hash algorithms and their outcomes given the input string MARCELLA, using a hash calculator function of the hacking tool Cain & Able. MD5 and SHA-1 hash algorithms are used extensively in the computer world to identify specific files, although both have been found to have collision problems and will be replaced by more mature algorithms in the future.

image from book
Figure 4-3

When Hashes Are Used

When a user types in a password for the first time, it is hashed and stored either locally in the SAM database or in a domain authentication database. No matter which authentication protocol you use (i.e., LM, NTLM, NTLMv2, or Kerberos) the stored password hashes use either LM or NT hash algorithms, or both. Every time a user logs on to Windows and types in his or her password, it is hashed, but Windows logon password hashes are rarely sent across the network.

LM or NT hashes

Windows logon passwords are hashed using one or two hash algorithms: LAN Manager (LM) and the Windows NTLAN Man (NT). The LM password hash has been used since the days of MS-DOS and Windows 3.11. LM password hashes are still stored by default in every authentication database, including Windows Server 2003 (by default). Windows NT introduced the NT password hash (also incorrectly called the NT hash by many resources). By default, Windows NT and later authentication databases will store both the LM and NT password hashes for any logon password for a user, computer, or service account.

Note 

Many sources call the NT password hash the NTLM password hash. This book will use the more common, and correct, NT form to further differentiate the NT hash from the NTLM authentication algorithm.

LAN Manager Hash

Invented by IBM and used by Microsoft, the LM hash is not a strong hash. In fact, it is so insecure and weak that most cryptographic experts refuse to call it a hash. Here's how the LM password hash is created:

  1. Even though a password can be up to 127 characters long, the LM hash truncates all characters past the fourteenth position. If the password is less than 14 characters long (which is likely), the password is padded with easy to recognize null characters. This effectively negates the password strength to a maximum of 14 characters (but actually it gets worse).

  2. All lowercase alphabetic characters are converted to uppercase. Thus, password guessers and crackers can eliminate all lowercase letters. The 94 keyboard character set is reduced to 68 characters. If the password contains only alphabetic characters, the hacker has only 26 characters to deal with—or 23 if you pull out the rarely used q, x, and z letters.

  3. Next, the 14-character password representation is split into two 7-character halves. Each half is then treated on its own, effectively making each password half equivalent to a 7-character password. Therefore, even when the user types in a 128-character password, its effective security is about 7 characters if the password cracker can capture the hash.

  4. Each half is used as an encryption key run through the DES symmetric cryptographic algorithm against a secret key (actually it is the constant "KGS!@#$%") to create two 64-bit outputs.

  5. Both 64-bit strings are combined to make one 128-bit string that is stored as a 32-byte hexadecimal string (but the two separate 16-byte halves are still easily split into their separate origins).

Hence, the LM hash breaks all sorts of hash cryptographic rules, including the glaring problem that passwords, for example, of MARCELLA and marcella will result in the same LM hash. Any passwords whose first 7 characters are identical will result in the same LM hash. Thus, MARCELLA, MARCELL, marchella123456, and maRcellbD all result in the same LM hash: C49DB4F38D5492F5.

To be fair, passwords longer than 7 characters that share the same first 7 characters will result in a second LM hash component that may or may not be identical. But any password sharing the same first 14 characters will always have the same LM hash(es). Microsoft stores a null LM hash (i.e., a fake hash) for passwords longer than 14 characters or if LM password hashing is disabled. The null LM hash is

 AAD3B435B51404EEAAD3B435B51404EE 

which is the 16-bit null hash value AAD3B435B51404EE repeated twice. If you see the null hash repeated twice, it means that the password is longer than 14 characters or LM password hashing is disabled. If the password is shorter than 8 characters, only the second half of the LM hash will contain the null hash value—allowing password crackers to estimate password size as above or below 8 characters in size.

To be clear, if a password cracker can capture non-null LM password hashes, there is a high likelihood that they can convert the LM hashes to their originating passwords. An excellent summary of the LM hash algorithm can be found at www.harper.no/valery/PermaLink,guid,.aspx.

NT Hash

Because the LM hash was so easy to break, Microsoft invented the NT hash. The NT hash overcomes many LM hashing problems. First, the NT hash is case sensitive, meaning it will not convert lowercase characters to uppercase. Second, long passwords are not truncated to the first 14 characters, and passwords are not padded with null characters. Lastly, NT hashing supports the full Unicode character set. Here's how a password is hashed with the NT hash algorithm:

  1. The password is converted into a 16-bit Unicode string.

  2. The Unicode string is hashed using the MD4 hash algorithm to make a 32-byte hexadecimal string.

NT hashing looks pretty simple, but the secrecy is in the fact that Microsoft used a more cryptographically sound hash algorithm (i.e., MD4) instead of making their own, and they no longer artificially truncate the original password.

NT password hashes have withstood the test of time and so far have not been found to be trivial to exploit. Password crackers have a hard time breaking NT hashes. LM hashes can often be compromised in seconds—the longest I've heard an LM hash crack taking is 1–2 days. NT password cracking, on the other hand, often takes days to months when the passwords are reasonably strong. In Figure 4-4, the Cain & Able program is being used to brute-force crack an NT password hash. As you can see in the figure, Cain & Able is predicting it might take 7.59 × 1010 years of cranking before it discovers the originating password. Note that this example shows the power of NT hashes used with long passwords.

image from book
Figure 4-4

Windows Passwords Aren't Salted

A weakness with Windows password hashes is that they are not salted. Salted hashes are like regular hashes, except that a random value is added or mathematically applied to the password prior to any of the hashing functions. This ensures that no two identical passwords result in the same password hash. In the Unix/Linux world, passwords are often hashed one of 4,096 different salt values and the salt value is stored where it can be easily retrieved. Although retrieving the salt was intended to be easy, it still adds extra protection beyond that afforded to a Windows computer.

Microsoft's choice of not salting passwords has consequences. Extracting hashes (as shown below) can easily be accomplished. If an attacker notices several (non-null) accounts with the same password hash, if they crack the hash, the password is the same on all related accounts. Administrators often use the same password across all their highly privileged accounts. Non-salting makes password attacks easier.

Protecting Password Hashes Using Syskey

Instead of using salts, Windows relies on hash encryption. Starting with Windows 2000, all passwords stored in the local SAM database (but not Active Directory) are encrypted by default. Microsoft created a password hash encryption utility, Syskey in Windows NT 4.0 Service Pack 2, and mandated its use by default in Windows 2000. The SAM password database (located at \%systemroot%\system32\config (SECURITY and SAM files)) is encrypted by a master encryption key (64-bit or 128-bit depending on the version of Windows). Without Syskey, the master encryption key is stored in such a way that it is easily accessible to intruders if they boot around the operating system (e.g., using a Linux boot diskette).

With Syskey, the master key (also called the local system key) can be protected by the Syskey utility. It has three modes, which indicate where the master key is located:

  • Local (default). The master key is stored locally in an obfuscated state on the local disk.

  • The master key comes from the user typing in a password during bootup.

  • The master key is removed from the system and stored on a floppy drive.

To use Syskey, follow these steps:

  1. At a command prompt, type Syskey, and then press Enter.

  2. In the Securing the Windows Account Database dialog box (see Figure 4-5), note that the Encryption Enabled option is already selected and is the only option available. When this option is selected, Windows will always encrypt the SAM database.

  3. Click the Update button.

  4. Click Password Startup if you want to require a password to start Windows. Use a complex password. The startup password must be at least 12 characters long and can be up to 128 characters long. Note: If you must remotely restart a computer that requires a password (if you use the Password Startup option), a person must be at the local console during the restart. Use this option only if a trusted security administrator will be available to type the startup password.

  5. Click System Generated Password if you do not want to require a startup password. Select either of the following options:

    • Click Store Startup Key on Floppy Disk to store the system startup password on a floppy disk. This requires that someone insert the floppy disk to start the operating system.

    • Click Store Startup Key Locally to store the encryption key on the hard disk of the local computer. This is the default option. Click the OK button two times to complete the procedure.

  6. Remove the SAM encryption key from the local hard disk by using the Store Startup Key on Floppy Disk option for optimum security. This provides the highest level of protection for the SAM database. Always create a backup floppy disk if you use the Store Startup Key on Floppy Disk option. You can restart the system remotely if someone is available to insert the floppy disk into the computer when it restarts.

image from book
Figure 4-5

It is important to remember that Syskey was invented to prevent local intruders from readily accessing local SAM database hashes. There are some important caveats: First, once the computer is booted up, Syskey provides no protection. Second, Syskey is meant to prevent intruders from stealing passwords, but it does nothing to prevent a local intruder from resetting a password. Unfortunately, all passwords are stored in a known place in the SAM and it is trivial for a local intruder to completely blank or reset a particular user's password (including the Administrator's password). But if a local intruder has this type of local access, there are many other issues to be concerned with as well, and resetting local passwords is just one problem. Third and last, there have been hacking utilities developed that get around Syskey's protections, especially the default mode, but again just refer to the previous sentence. Administrators wanting strong local SAM protection should look into cryptographically sound external cryptographic hardware modules or BIOS hard drive encryption. A common feature on computers today is hard drive encryption built into the BIOS. Another simple protection is to prevent booting on any media other than the primary boot hard drive. Then attackers can't boot around the OS's protections and attack Syskey.

Windows Authentication

Sending password hashes across the network would open them up to network sniffing attacks. The attacker could sniff the network, extract the hashes, and then crack them to find the password. Actually, this is a legitimate form of password cracking, but Windows attempts to prevent this type of attack.

Most of today's popular operating systems don't send password hashes across the network. Instead they use a challenge-response mechanism. With challenge-response, when the client wants to log on, it sends a logon request to the local or domain authentication service (along with the local machine, workgroup, or domain name) and request to log on. The authentication service randomly creates a series of bytes (called the challenge) and sends it back to the client computer. The client takes the challenge and cryptographically manipulates the challenge according to an authentication protocol algorithm, using its password hash as one of the keys, and sends back the result (called the response). The logon authentication service runs the challenge through the same process the client used, and if the two results match, the client is authenticated.

The nice feature of challenge-response authentication is that neither the password nor the password hash is sent across the network, but both the client and the server must have the same stored password hash in order to create identical responses. In order for the client to send the correct response, it must have the correct password hash, and have directly inputted the correct password. It's a beautiful system when it works as intended.

Note 

Challenge-response mechanisms make it more difficult for password crackers to discover the plaintext passwords, but it only complicates the task—it is not impossible.

Windows Authentication Protocols

Windows computers use one of four authentication protocols: LAN Manager (LM), NTLM version 1.0 (NTLM), NTLM version 2.0 (NTLMv2), or Kerberos.

LM Authentication

Like LM password hashes, the LM authentication protocol was created a long time ago and is considered easily exploitable. The LM authentication process flows like this:

  1. The client makes an authentication request to the server.

  2. The server generates a 16-byte random number, called a challenge, and sends it to the client (called a Type 2 message).

  3. The LM hash of the password is created.

  4. The 16-byte LM hash is null-padded to 21 bytes.

  5. This value is split into three 7-byte thirds.

  6. These values are used to create three DES keys (one from each 7-byte third).

  7. Each of these keys is used to DES-encrypt the challenge from the Type 2 message sent by the authenticating server (resulting in three 8-byte ciphertext values).

  8. These three ciphertext values are concatenated to form a 24-byte value. This is the LM response, which is sent to the server.

  9. The server does the same calculation on its side, and then compares the response from the client. If the response matches the value calculated by the server, then the client is authenticated.

LM authentication remains a default authentication protocol for backward compatibility issues. LM is used to authenticate to early Microsoft LAN Manager (a pre-OS/2 network OS) servers, Windows 3.11, and Windows 9x systems. It is even used to authenticate Windows CE devices. Several cryptographers analyzed the LM authentication protocol and found it lacking.

NTLM

Microsoft created the NTLM authentication protocol with Windows NT. NTLM authentication works as follows:

  1. The client makes an authentication request to the server.

  2. The server generates a 16-byte random number, called a challenge, and sends it to the client (called a Type 2 message).

  3. The client creates an NT hash of the password (as discussed previously, this is the MD4 digest of the Unicode mixed-case password).

  4. The 16-byte NT hash is null-padded to 21 bytes.

  5. This value is split into three 7-byte thirds.

  6. These values are used to create three DES keys (one from each 7-byte third).

  7. Each of these keys is used to DES-encrypt the challenge from the Type 2 message (resulting in three 8-byte ciphertext values).

  8. These three ciphertext values are concatenated to form a 24-byte value. This is the NTLM response. The client sends the NTLM response to the server.

  9. The server sends the following three items to the authentication server/service: username, the challenge sent to the client, the response received from client.

  10. The authentication service retrieves the hash associated with the user, and then uses the hash to encrypt the challenge in a similar way.

  11. If the result and the client's response match, authentication is successful and the DC responds to the server.

NTLMv2

Although NTLM authentication is significantly more secure than LM, another cryptographic review showed it to be trivial to exploit. Microsoft released version two of NTLM in Windows 2000 and back ported it to Windows NT in Service Pack 4. NTLMv2 fixed most of the noted weaknesses in NTLM. The NTLMv2 authentication process is as follows:

  1. The client makes an authentication request to the server.

  2. The server sends the client a Type 2 message challenge.

  3. The client obtains the NT password hash.

  4. The Unicode uppercase username is concatenated with the Unicode uppercase authentication target (domain or server name).

  5. The HMAC-MD5 message authentication code algorithm (described in RFC 2104) is applied to this value using the 16-byte NT hash as the key. This results in a 16-byte value —the NTLMv2 hash.

  6. A block of data known as the blob is constructed. The blob includes a timestamp, a client challenge, and other information from the Type 2 message.

  7. The challenge from the Type 2 message is concatenated with the blob.

  8. The HMAC-MD5 message authentication code algorithm is applied to this value using the 16-byte NTLMv2 hash (calculated in step 3) as the key. This results in a 16-byte output value.

  9. This value is concatenated with the blob to form the NTLMv2 response. The client sends the NTLMv2 response to the server.

  10. The server sends the following three items to authentication server/service: username, the challenge sent to the client, the response received from the client.

  11. The authentication service retrieves the hash associated with the user, and then uses the hash to encrypt the challenge in a similar way.

  12. If the result and the client's response match, authentication is successful and the client is successfully authenticated.

NTLMv2 has withstood the test of time and to date no exploits have been announced. NTLMv2 is harder to brute-force attack because it uses a 128-bit encryption key. Most attacks against NTLMv2 are only successful because of weak passwords (weak passwords will always do in strong authentication). For more information, check out http://davenport.sourceforge.net/ntlm.html, www.securityfriday.com/Topics/ntlm_optimizedattacks.html, and http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/Security/microsoft_ntlm.asp.

Kerberos Basics

With Windows 2000, Microsoft created another authentication protocol. This time they picked a widely used open-source protocol created by MIT. Kerberos is only used in Windows 2000 and later domains involving domain logins. Local logins use one of the other three authentication protocols.

Writing about how Kerberos works could fill an entire chapter. The complexity, details, and nomenclature is astounding. Most students are introduced to Kerberos and all its complex terminology and end up not learning the basics of how Kerberos works, so instead of boring you with inane detail, this section describes it as basically as possible and leaves it up to you to decide whether you want to learn more about Kerberos.

The MIT version of Kerberos was developed with the authentication services being split among two or more Kerberos servers. In Windows, however, any Windows 2000 or later domain controller in a 2000 or later domain can act as the sole Kerberos server. Kerberos uses symmetric key encryption, and all participating computers' time must be within five minutes of the domain controller's time (by default). Here is a Kerberos summary:

  1. The user authenticates itself to the domain controller as it normally would (Kerberos uses the NT password hash).

  2. The Kerberos Authentication Service gives the client a token called a Ticket Granting Ticket (TGT), which basically says the client is authenticated and can ask for session tokens. By default, the TGT is good for 10 hours. During this period, the client should not have to resubmit its logon credentials and be re-authenticated to any Kerberized server or service on the network. This minimizes the time authentication credentials spend on the network.

  3. When the client needs to access a server process or service, it asks the Kerberos Ticket Granting Service (TGS) on the domain controller for a session ticket.

  4. The Ticket Granting Service approves the request and gives the client a session ticket. The session ticket has been encrypted using the remote server's Kerberos token so that only the remote server can read it.

  5. The client then hands the server it wishes to access the session ticket.

  6. The server validates the session ticket and allows the client to access the process or service.

A slightly more detailed look is the Kerberos Authentication Service (AS) exchange:

  1. The client's computer converts the entered password to the long term key.

  2. The client computer creates a ticket request and then encrypts authentication credentials that include the current system time with the long term key. It sends this request to the Kerberos Distribution Center (KDC) service (i.e., the domain controller).

  3. The KDC looks up the principal and its long term key from the Active Directory database. It uses the long term key to decrypt the authentication credentials, and compares the time against its local system clock. If the data can be decrypted and the time is within an acceptable window of difference, the identity is confirmed.

  4. The KDC creates a session key for the client to use in future communications with the KDC. It also creates a user ticket specific to the KDC service that also contains the session key encrypted with the KDC's long term key. It encrypts a portion of the original time authentication credentials and the new session key with the client's long term key. It sends this encrypted data along with the ticket to the client's computer.

  5. The client's computer decrypts the authentication credentials (i.e., TGT) to validate that the KDC actually has access to the long term key (i.e., mutual authentication), decrypts the session key, and stores it with the user's ticket in the credential cache.

  6. After obtaining the TGT, the user will obtain a Kerberos session ticket for the computer on which the user is authenticating.

Kerberos Ticket Granting Service (TGS) exchange:

  1. The client's computer creates a new ticket request for a resource, encrypts new authentication credentials (including a timestamp) with the KDC session key, and includes the user ticket. The data is sent to the KDC.

  2. The KDC uses its own long term key to decrypt the user ticket and extract the session key. It then uses the session key to decrypt the authentication credentials. If the two match, it knows that the user was previously authenticated.

  3. The KDC then processes the request for the new session ticket by looking up the resource server's long term key. It creates a new session key and encrypts it with the existing session key. It encrypts a portion of the original authentication credentials with the existing session key, and encrypts a service ticket with the resource server's long term key. This is all sent back to the client's computer.

  4. The client's computer uses the existing session key to decrypt the authentication credentials, again assuring mutual authentication. It decrypts the new session key with the existing session key and stores it in the credential cache with the new service ticket.

Kerberos Client/Server exchange (the Application Exchange):

  1. The client's computer retrieves the session key and service ticket for the resource server. It uses the session key to encrypt the authentication credentials and timestamp. The computer then includes an authentication request, the encrypted authentication credentials, and the resource server service ticket.

  2. The resource server uses its long term key to decrypt the service ticket and retrieve the session key. It then uses the session key to decrypt the authentication credentials and compares the time to its own local time.

  3. The resource server encrypts a portion of the original authentication credentials and encrypts it with the session key to prove its identity back to the client's computer (i.e., mutual authentication again).

Once authentication has completed, the server creates a local access token for the user that contains the SIDs of the user and any groups to which the user belongs, as covered in Chapter 3. You can use W2K Server Resource Kit utilities such as Klist and Krbtray (www.microsoft.com/downloads/thankyou.aspx?familyId=&displayLang=en) to see the Kerberos tickets and keys in the credential cache. Microsoft has also released a Kerberos Network Monitor parser to help interpret network traffic captures of authentication traffic.

The benefits of Kerberos include the following:

  • Mutual authentication—All participating parties authenticate to each other. Many authentication protocols are only one-way.

  • Increased password protection because the initial authentication credentials are minimally retransmitted across the network

  • Replay attack protection because of the timestamps

  • Delegation of identity—This was covered in Chapter 3. Kerberos allows constrained delegation.

  • Interoperability—Kerberos is an open standard (although Windows has its own Kerberos twists) and is supported by many operating systems, although interoperability can be a major challenge at times.

To date, Microsoft's version of Kerberos has withstood most attacks. MIT's Kerberos version is found to contain a vulnerability about twice a year. Microsoft's version has had only one report of a vulnerability and that is when the initial authentication takes place. If network sniffers can capture the initial authentication traffic, they can capture the NT hash and attempt to brute force it (covered more below). For more information on Kerberos, see the information at http://support.microsoft.com/default.aspx?scid=kb;EN-US;217098 and http://support.microsoft.com/kb/q266080.

What Protocols When?

Windows 2000 and later can use all four authentication protocols. Windows 3.x and earlier can only do LM authentication. Fully patched Windows 9x and NT clients can do LM, NTLM, and NTLMv2 but cannot do Kerberos. Windows 9x clients need the Directory Services client to use NTLMv2, and NT needs Service Pack 4. Kerberos cannot be used as follows:

  • With or to connect to Pre-Windows 2000 computers

  • To connect domain computers to non-domain computers

  • For authentication between non-domain computers

  • When connecting to computers outside the forest trust

  • On LANs where TCP/IP port 88 (UDP or TCP) is blocked between the client and the KDC

  • For local logons

  • With connections made with IP addresses only (there is a slightly complicated workaround)

  • For Routing and Remote Access Services (RRAS) logons

  • For Windows FTP and Telnet connections (without additional third-party software)

On Windows 2000, by default, Kerberos will be used to connect to any Windows 2000 and later domain controller or domain computer. If a Windows 2000 or later computer connects to an NT domain or a pre-Windows 2000 resource or local computer, it can be forced back to one of the other three modes.

Herein lies the problem. Windows 2000 and later must use Kerberos and at least one of the other three protocols. As discussed above, Kerberos and NTLMv2 are relatively secure protocols and should be the only authentication protocols used. Unfortunately, by default, Windows 2000 and later computers can use any of the four, and hackers can often force the older, insecure authentication protocols to be used.

There are many ways to trick a client computer into connecting to a rogue computer without the user's knowledge:

  • The malicious hacker sets up a rogue web site and sends the user an e-mail with an embedded graphic link. If the user's e-mail doesn't prevent HTML content, when the user opens his or her e-mail, the embedded link can connect back to the attacker's rogue web server to download a small image. The rogue web server can be running IIS and request that the user's computer authenticate to the web server. The web server can tell the user's PC to use LM authentication. By default, when asked to authenticate, Internet Explorer, Outlook, or Outlook Express will authenticate with the user's currently logged on credentials. Today, most versions of Internet Explorer and the Microsoft e-mail clients will not send the user's currently logged in credentials to non-intranet sites without first asking, though early versions would. You can determine whether or not Windows tries to log into remote web sites with current credentials by modifying a setting in Internet Explorer (see Figure 4-6).

    Note 

    Many e-mail applications can selectively suppress the download and display of remote graphics, even if they display embedded graphics and other HTML message features.

  • The user can be sent a malicious Microsoft Word document with an embedded link to a remote rogue web server. When the user opens or closes the document, a NetBIOS session is initiated to the remote web server. In Windows 2000 and later, the Web Client service will attempt to authenticate if requested by the remote server (see www.securityfriday.com/Topics/winxp3.html for more details).

  • When a user clicks on Network Neighborhood, Windows will try to acquire a list of every available NetBIOS resource on the local LAN. A properly located intruder could trick the user's PC into authenticating to its malicious server.

  • On a note related to the previous bullet point, by default Windows XP and later computers will seek out all NetBIOS resources on the local LAN whenever they are started. To prevent this behavior you must disable the Automatically search for network folders and printers option under Folder Options and Tools in Windows Explorer.

  • Many hacker programs (see "SMB Attack Tools," below) can use the SMB protocol to force a Windows machine to incorrectly authenticate to the intruders machine.

image from book
Figure 4-6

image from book
SMB/NetBIOS

Server Message Block (SMB) is a communication protocol used for sharing files and other resources. Windows' implementation of SMB is called NetBIOS, but many operating systems, including Unix/Linux, use SMB (often using an open-source software program called Samba).

Windows NetBIOS works over ports 137, 138, 139, and 445 (Windows 2000 and later) and it is mostly used to map network drives, and to share folders and printers. In Windows 2000, Microsoft added NetBIOS over TCP/IP (NbT), because the original NetBIOS implementation was not easily routable.

Unless extremely hardened, every Windows system has its NetBIOS ports exposed to the network and will attempt to make connections (and accept connection attempts) to and from other NetBIOS computers on the network. Windows spends a lot of its time in the background sending and receiving NetBIOS traffic. It is in a large part how Windows works and how it populates the Network Neighborhood and Network browse lists. Many people are told that NetBIOS isn't needed anymore on today's Windows computers because of the increasing reliance on DNS resolution. This is hugely incorrect. A Windows computer without NetBIOS enabled doesn't communicate well with other Windows computers. Even Active Directory, which is closely tied to DNS, will not install without NetBIOS, and NetBIOS name resolution is still frequently used by Windows for many tasks.

Because NetBIOS is always available on any Windows computer and will activate with the slightest prodding, it is a favorite hacker target. Poorly secured Windows computers will accept, unbeknownst to the user, network drive mappings from other computers. And any Windows computer can easily be tricked into establishing network connections in the background.

Outbound NetBIOS connection attempts usually contain the currently logged in user's authentication credentials in obscured form. Windows authentication protocols (covered below) attempt to protect the authentication credentials from being converted to their plaintext original form by unauthorized intruders. Hackers have a variety of tools and techniques (many discussed in this chapter) to exploit NetBIOS mechanisms.

image from book

When any of these behind-the-scenes connections are made, the user's computer can be tricked into making an authentication request to the malicious server. The malicious server can then ask the client's PC to use the LM protocol, which the client's computer (by default) will happily do. The malicious computer can then capture the LM authentication process credentials and easily crack the password. We will discuss defenses against these sorts of attacks below.

Logon Process

During a normal Windows interactive logon, the Winlogon.exe process is responsible for managing the security-related user interactions to Windows, including the logon and logoff processes. Winlogon.exe calls the Msgina.dll (Graphical Identification and Authentication interface), which displays the standard logon box. Msgina.dll prompts the user for a logon name, password, and potentially more information, such as the domain name. The Winlogon process passes the inputted information securely to the Local Security Authority process (Lsass.exe), which determines whether the logon request must be authenticated locally or against a domain database and whether it requires LM, NTLM, NTLMv2, or Kerberos authentication (see Figure 4-7). Behind the scenes, Kerberos authentication is handled by something called the Kerberos authentication package, and the other types are handled by the MSV1_0 authentication package. You will sometimes see those names in the Windows event log, so it can't hurt to know what they are referring to.

image from book
Figure 4-7

One of the authentication protocols (LM, NTLM, NTLMv2, or Kerberos) is used to transmit the security principal's authentication credentials between the client computer and the server. A password hash is used during the authentication process. If the security principal is successfully authenticated, it is assigned a session ID, and the security access token is created (covered in Chapter 3). For most resource accesses from this point on, the user need only hand over the already authenticated identity and access token. The security reference monitor then determines whether the security principal is authorized to access the resource.

If the user supplies the wrong password, when the server being accessed is a domain controller, it contacts the domain's PDC emulator service. The PDC emulator service runs on a domain controller in each domain and is the ultimate storage place of security principal passwords. If a user changes their domain account password, the change is propagated from their computer to the PDC emulator. If the PDC emulator agrees with the server computer that the security principal has supplied a bad password, the server will then send a failed logon message back to the client and write an event to the Security log if so configured. A data field that tracks successive bad logon attempts is incremented by one. If the Account Lockouts (covered below) feature is turned on, and the maximum threshold figure is reached, the account may be locked out for the lockout duration period; although interestingly, in Windows Server 2003, if the security attempted to log on with a password identical to their last previous password (stored in the password history field), the bad logon attempt counter is not incremented.



Professional Windows Desktop and Server Hardening
Professional Windows Desktop and Server Hardening (Programmer to Programmer)
ISBN: 0764599909
EAN: 2147483647
Year: 2004
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net