Q: What’s the SIDHistory Active Directory (AD) attribute, and how can a malicious user exploit it to mount elevation-of-privilege attacks against AD?
A: In Windows 2000, Microsoft added the SIDHistory attribute to AD user account objects. SIDHistory facilitates resource access in inter-domain account migration and intra-forest account-move scenarios. For example, when you migrate a user account from a Windows NT 4.0 domain to a Win2K domain, Windows can populate 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. At logon, when the user’s authorization data (e.g., group memberships) are gathered in the Win2K domain, the domain controller (DC) also adds the user’s old SID and the old SIDs of the groups the user belonged to--which are stored in the SIDHistory attribute--to the authorization data. Therefore, you don't need to update the ACLs of the resources in the old domain with the new SIDs. Users can continue to access the resources located in the old domain with their new account.
The SIDHistory exploit is based on the concept that a malicious AD administrator might try to modify the SIDHistory attribute of a user account object to elevate its privileges. Looking at a trust relationship between two domains, for example, the administrator of the trusted domain could try to add an administrator account SID of the trusting domain to the SIDHistory attribute of a user account in the trusted domain. The user account of the trusted domain then would get administrator access to the trusting domain. In the first Win2K releases, the DCs of the trusting domain wouldn't check the authorization data included with incoming resource access requests from the trusted domain. They automatically assume the requests contain only SIDs for which the DCs of the trusted domain are authoritative. Tools are available to help malicious administrators populate the SIDHistory attribute of AD user accounts. A good example is the SHEdit tool that you can download from http://www.tbiro.com/projects/SHEdit/index.htm. Although modifying the SIDhistory attribute isn’t easy (you can modify it only if AD is in offline mode), it is possible.
A malicious administrator could carry out this attack in any kind of Windows domain trust setup: between the domains of a single forest, and between domains that are linked using an external or forest trust relationship. In a single forest setup, for example, rogue child-domain administrators or any rogue user with physical access to a DC can attempt to leverage the SIDhistory exploit to elevate themselves to Enterprise Administrators.
To mitigate the risks related to the SIDhistory attribute, you must in the first place make sure that Enterprise Administrators and Domain Administrators are highly 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 attack.
With trust relationships that are set up between forests and trust relationships set up with external domains (in this context, external means “not in the proper forest”), you can use the SID filtering feature to quarantine domains. When SID filtering is enabled, the DCs of the trusting domain will check whether incoming authorization data is related to the trusted domain. The DCs will automatically remove 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 values in the SIDHistory attribute, SIDHistory and SID filtering are mutually exclusive features.
SID filtering is available only with Win2K Service Pack 2 (SP2) and later. You can turn the feature on or off using the Netdom command-line utility: Use the trust and /filtersids switches as described in the Microsoft article "MS02-001: Forged SID could result in elevated privileges in Windows 2000" (http://support.microsoft.com/?kbid=289243). For Windows Server 2003 domains use the trust and /quarantine netdom.exe switches. SID filtering is turned on by default on Windows 2003 external and forest trust relationships.
Don't use SID filtering on trust relationships between domains in the same forest. Doing so breaks AD replication and transitive trust relationships. If you want to quarantine a domain, you should put it in a separate forest.
