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.
If you enable nolmhash in a clustered Windows 2003 or Win2K environment, you must make sure that the Cluster service account password is at least 15 characters long. If you don't do this, you'll experience problems when using the Cluster Administrator tool. See the Microsoft article "Cluster service account password must be set to 15 or more characters if the NoLMHash policy is enabled" at http://support.microsoft.com/?kbid=828861 for more information about this issue.
To ensure that your users are using the stronger NTLMv2 authentication protocol, you must make the NTLMv2 software logic available to users that are running older Windows platforms. On Win98 and Win95 systems, install the Directory Services client, which you can download at http://down load.microsoft.com/download/0/0/a/00a71 61e-8da8-4c44-b74e-469d769ce96e/dsclient9x.msi. The NTLMv2 logic is available on Windows 2003, XP, Win2K, or any NT machine running SP4 or later.
To force your clients to use NTLMv2 in a Windows 2003 or Win2K AD environment, you can set the Network Security: LAN Manager Authentication Level GPO setting to the value Send NTLMv2 response only, refuse LM. You can get the same effect by setting the corresponding registry subkey, HKEY_LOCAL_MACHINE\SYSTEM\Current ControlSet\Control\Lsa\lmcompatibilitylevel (REG_DWORD), to value 4. This subkey and its values are also documented in the Microsoft article "LmCompatibilityLevel" at http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/regentry/76052.asp.
Finally, Windows won't generate an LM hash if users honor these password rules:
- Use a password that's longer than 14 characters, or
- Use certain ALT characters in the password. To enter these ALT characters, type a four-digit numeric code while holding down the ALT key. The ALT characters that prevent an LM hash are listed in Web Figure 1.
ATTACK TWO
Cracking Passwords Based on Kerberos Preauthentication Data
For a long time, we assumed that when we used the default Kerberos authentication provider on Windows 2003, XP, or Win2K machines to protect our passwords, brute-force password cracking attacks such as the ones outlined in the previous section couldn't be successful. But in late 2002—2 years after the release of Win2K—a tool named KerbCrack appeared on the Internet. KerbCrack—which is made up of two tools, kerbsniff and kerbcrack—can perform brute-force cracking attacks on Kerberos packets. Kerbsniff captures Kerberos packets from the network, and kerbcrack performs the actual brute-force cracking on the output of the first tool. Both tools can be downloaded from http://www.ntsecurity.nu/ toolbox/kerbcrack. A paper outlining a similar attack but using different tools is available from http://www.hut.fi/~autikkan/kerberos/docs/phase1/pdf/LATEST_password_attack.pdf.
Kerberos preauthentication is a feature that was introduced in Kerberos 5.0. A client uses preauthentication data to prove the knowledge of its password to the Kerberos Key Distribution Center (KDC—the Kerberos service running on every Windows 2003 and Win2K DC) so that the client can be issued a Ticket Granting Ticket (TGT). Kerberos cracking attacks target the encrypted timestamp that's embedded in the Kerberos preauthentication data. The timestamp is encrypted by using the user's master key (i.e., a key that's based on the user's password).
ATTACK TWO
Prevention
There are two ways to protect against Kerberos preauthentication attacks: Use Windows smart card logon, or encrypt the network traffic between the Kerberos client and the DC by using IPsec. Windows smart card logon uses a Kerberos extension called PKINIT, which doesn't encrypt the packet by using the user's master key but rather uses the user's private key. For more information about PKINIT, see "Public Key Cryptography for Initial Authentication in Kerberos" at http://www.ietf.org/proceedings/03mar/ I-D/draft-ietf-cat-kerberos-pk-init-16.txt. At this point in time, it's impossible to perform a brute-force attack on packets that are secured by using public-private key cryptography. For more information about configuring IPsec, have a look at the Windows IT Security article "Using IP Security Policies to Restrict Access to a Server," March 2005, InstantDoc ID 45217, and "Assigning IPsec Policies to Servers and Workstations on Your Network," March 2003, InstantDoc ID 37946.
ATTACK
THREE
Privilege Elevation by Using SIDHistory
Microsoft added the SIDHistory attribute to AD user account objects in Win2K. SIDHistory facilitates resource access in interdomain account migration scenarios and intraforest account move scenarios. For example, when a user account is migrated from an NT 4.0 domain to a Win2K domain, Windows automatically populates the SIDHistory attribute of the newly created user account in the Win2K domain with the SID of the corresponding user account in the NT 4.0 domain. When at logon, the user's authorization data (group memberships and so on) is gathered in the Win2K domain, the DC adds the user's old SID from the SIDHistory attribute to the authorization data. The resources located in the old domain don't have to be re-permissioned (i.e., their ACLs don't need to be updated); users can continue to access them, even with a new account.
A malicious AD administrator could try to modify the SIDHistory attribute of a user account object to elevate its privileges. For example, in a domain trust relationship, the administrator of the trusted domain could try to add the SID of an administrator account in the trusting domain to the SIDHistory attribute of a user account in the trusted domain. If the administrator were successful, the user account of the trusted domain would get administrator access to the trusting domain.
In the first releases of Win2K, the DCs of the trusting domain don't check the authorization data included with resource access requests from the trusted domain. The trusting domain DCs automatically assume that the requests contain only SIDs for which the DCs of the trusted domain are an authoritative source.
Although modifying the SIDHistory attribute of AD user accounts isn't easy (it can be done only when AD is in offline mode), it's possible. Tools are available that help malicious administrators populate the SIDHistory attribute. A good example is the SHEdit tool that can be downloaded from http://www.tbiro.com/projects/shedit/index.htm.
This attack can be carried out in any kind of Windows domain trust setup: between the domains of a single forest or between domains that are linked by an external or forest trust relationship. In a single forest setup, for example, rogue child-domain administrators or any rogue users with physical access to a DC could attempt to leverage the SIDHistory vulnerability to elevate themselves to the Enterprise Administrators group.
ATTACK THREE
Prevention
To mitigate the risks related to the SIDHistory attribute, you must make sure that members of the Enterprise Admins group and Domain Admins groups are very trusted individuals. You must also ensure a high level of physical security on your DCs to prevent rogue users from taking DCs offline and exploiting this vulnerability.
To prevent an administrator from changing the SIDHistory attribute, you can also use the SID filtering feature on trust relationships set up between domains in different forests. SID filtering allows administrators to quarantine domains. When SID filtering is enabled, the DCs of the trusting domain check whether the authorization data included with resource access requests from the trusted domain is related to the trusted domain. The DCs of the trusting domain automatically remove the SIDs that aren't related to the trusted domain. Because this operation also removes SIDs that were added to the authorization data because of the SIDHistory attribute, SIDHistory and SID filtering are mutually exclusive features.
SID filtering is available in Win2K SP2 and later. You can turn it on or off by using the netdom.exe command-line utility; in Win2K, use the trust and /filtersids switches as described in the Microsoft article "MS02-001: Forged SID could result in elevated privileges in Windows 2000" at http://support .microsoft.com/?kbid=289243. In Windows 2003, use the trust and /quarantine switches. SID filtering is turned on by default for Windows 2003 external and forest trust relationships.
You shouldn't use SID filtering on trust relationships between domains in the same forest. Doing this breaks AD replication and transitive trust relationships. If you want to quarantine a domain, you should put it in a separate forest.
ATTACK FOUR
DoS Attack Based on Excessive AD Object Creations
Another way for users with administrator permissions to launch a Denial of Service (DoS) attack against AD is to flood it with new object creations. An authorized user can for example bring down an AD server by creating AD objects until the DC runs out of disk storage space. Another example is an authorized user adding many thousands of group members to a group by using one add command.
ATTACK FOUR
Prevention
To protect against this attack, you must again be extremely careful about whom you give AD object creation permissions to. Another feature you can use is the AD object quotas introduced in Windows 2003. A limited version of the object quota feature is also available in Win2K.
AD object quotas determine the number of objects that can be owned in an AD naming context (NC) or directory partition by a particular security principal. AD object quotas can be specified and administered separately for each AD NC and directory partition. However, you can't define them for the Schema NC. You can define a default quota for every AD NC and partition; if you don't explicitly set a default quota on a partition, the default quota for the partition is unlimited.
AD tombstone objects owned by a security principal are counted as part of the AD object quota consumption of the principal. Tombstone objects are temporary AD objects created when an AD object is deleted. AD uses them to keep deleted object data consistent across AD DCs. For each NC and partition, you can specify a tombstone quota factor that determines the weight given to a tombstone object in quota accounting. For example, if the tombstone quota factor for a given NC or partition is set to 25, then a tombstone object in the partition is counted as 0.25 of a normal AD object. The default tombstone quota factor for each partition is set to 100, so by default, a tombstone object has the same weight as a normal AD object.
You can assign quotas to every security principal, including the user, computer, group, and inetOrg-Person principals. A security principal can be covered by multiple quotas; for example, a user could be assigned an individual quota and also belong to a security group that has an assigned quota. In such a case, the quota that will be applied is the largest quota assigned to the security principal. Members of the Domain Admins and Enterprise Admins groups are exempt from AD object quotas.
AD object quotas are stored in the NTDS Quotas container of the AD NC or partition as objects of the msDS-QuotaControl class. To set an AD object quota of 10 for user Joe in the Accounting domain NC, you could type the following Dsadd command:
Dsadd quota -part DC=Accounting,DC=COM -acct Accounting\Joe -qlimit 10 -desc "Quota for Joe"
To change the tombstone quota factor for the Accounting domain NC to 25, you would type the following Dsmod command:
Dsmod partition DC=Accounting,DC=COM -qtmbstnwt 25
To change the default object quota setting to 0 for the Accounting domain NC, you would type the following Dsmod command:
Dsmod partition DC=Accounting,DC=COM -qdefault 0
Only DCs running Windows 2003 can enforce quotas. Quotas are enforced only on originating directory operations. They aren't enforced on replicated operations. To effectively use AD object quotas in an AD domain directory partition, all DCs in that domain must be running Windows 2003. To use AD object quotas in an AD configuration partition, all DCs in the forest must be running Windows 2003 (i.e., all domains and the forest must be at Windows 2003 functionality level 2). Realize that the availability of the AD object quota feature itself isn't related to any specific functionality level—it's available on any Windows 2003 DC. If a Windows 2003 domain that has quotas defined still has Win2K DCs, users can continue connecting to these DCs and work around the quota restrictions.
Win2K includes a very limited version of the Windows 2003 AD quota system. In Win2K, administrators can restrict how many computer accounts can be created by a particular user account. To do so, they must use the ms-DS-MachineAccountQuota attribute of the AD domain object. The restrictions don't apply to members of the Domain Admins and Account Operators groups. The ms-DS-MachineAccountQuota attribute is supported in Windows 2003 (the default value is 10). To disable the addition of computer accounts, you can set this attribute to 0.
A similar effect can be obtained by taking away the Add workstations to domain user right from the Authenticated Users group. In both Windows 2003 and Win2K, this right is given by default to the Authenticated Users group.
Playing All the Angles
The attacks outlined in this article underline the importance of taking a multipronged approach to securing an AD infrastructure. In addition to technology-focused security solutions, you must also think about physical and organizational security measures. Physical security measures include securing physical access to Windows DCs, your network infrastructure, and your organization's buildings. Organizational security measures include the creation of security policies and operational procedures, regularly performing external security audits of the AD infrastructure, and continuously training administrators and users on security risks and best practices. Securing AD is a big task that should be a high priority for a team of people in your organization that focuses on the combination of technical, physical, and organizational security.
