Deflect AD Attacks

Many of today's enterprises use Active Directory (AD) either as their enterprise directory or as the network OS (NOS) directory for their Windows infrastructure. AD has become an important asset in most enterprises, and valuable things must be protected accordingly.

AD can be attacked from many directions—let's look at five common attacks and how to protect AD against them. The first three attacks can result in an elevation of the privileges of the attacker in AD. The last attack in this print article and another attack described in the Web-exclusive sidebar "Attack #5: DoS Attack Based on the MaxTokenSize Property" (http://www.windowsitpro.com, InstantDoc ID 49352) can affect the availability of the AD infrastructure. Unless stated otherwise, the information in this article applies to both the Window Server 2003 and Windows 2000 Server versions of AD.

I can't address all AD attacks in this one article. My main goal is to show AD administrators the urgent need for taking a multipronged approach toward locking down and securing AD.

ATTACK ONE
Cracking Passwords Based on the LM Hash
Password cracking is the process of hashing a number of potential passwords by using the same hashing algorithms used by an OS, then comparing the results of the cracking operation to the password hashes stored by the OS. Password cracking can be time-consuming; password crackers typically have to try many (and sometimes, all) possible passwords. However, freeware tools such as John the Ripper and LCP can help automate password cracking. You can download the latest John the Ripper version from http://www .openwall.com/john. The latest LCP version can be found at http://www.lcpsoft.com/ english/index.htm. These tools can crack passwords particularly easily in AD environments that use the plain-vanilla NT LAN Manager (NTLM) authentication protocol. NTLM is the default authentication protocol of Windows NT 4.0 and is still supported in Win2K and later OS versions for down-level compatibility reasons. NTLM is made up of two authentication protocols: LM and NTLM. The two protocol flavors use different hashing algorithms; these hashes are referred to as the LM and the NT, or Unicode, hashes, respectively.

The way Windows generates the LM hashes contains weaknesses that can significantly speed up the password cracking process. One weakness is that passwords can't be longer than 14 characters. LM also limits the character set by converting all password letters to uppercase during the LM hash calculation. In addition, the LM hash doesn't actually use a hash function but rather a symmetric cipher to generate the hash.

Figure 1 shows how the LM hash is generated for the user password hpinvent1. First, the password is converted to uppercase: HPINVENT1. Next, the uppercase password is split into two seven-character strings: HPINVEN and T1*****. The second string is padded with null characters to make it a seven-character string. The two strings are then used as the keys to encrypt a constant by using the Digital Encryption Standard (DES) symmetric cipher, rather than a hash function (as mentioned above). Finally, the resulting DES-encrypted blobs are concatenated to create the LM hash.

ATTACK ONE
Prevention
To mitigate the risks posed by LM password hashes, you can do the following: Get rid of the LM hashes in the AD database, ensure that your Windows users are using the stronger NTLMv2 authentication protocol, or ensure that your users honor specific password creation rules.

You can prevent the storage of the LM hashes in the AD on Windows 2003, Windows XP, and later platforms with the following Group Policy Object (GPO) or Local Policy setting: Network security: Do not store LAN Manager hash value on next password change. In Win2K, this setting doesn't remove LM hashes from AD or the SAM (the local security database); it only ensures that LM hashes aren't stored the next time users change their password. Thus, after you make this change, you should force all affected users to change their passwords. In Windows 2003 and XP, the Network security: Do not store LAN Manager hash value on next password change setting does clear the LM hash history entries in the security database.

On Windows 2003, XP, and Win2K Service Pack 2 (SP2) or later platforms, you can also edit the registry directly to prevent LM hash storage. To do so, set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\nolmhash registry subkey (REG_DWORD) to value 1.

If you make this change in a domain environment, you must be sure to make it on all domain controllers (DCs). You shouldn't make this change if you have an environment in which users are still using Windows 98 or Windows 95 clients that don't have the Directory Services client (explained below) installed. These clients can use only LM authentication. The use of nolmhash is also outlined in the Microsoft article "How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases" at http://support.microsoft.com/?kbid=299656.

   Previous  [1]  2  3  4  Next