MS02-001: Forged SID could result in elevated privileges in Windows 2000
This article has been archived. It is offered "as is" and will no longer be updated.
Microsoft Windows NT and Windows 2000 protect system resources with access control lists (ACLs). ACLs are lists of security identifiers (SIDs) and lists of access rights or permissions that are granted to that security principal. SIDs are relative to a domain. The SID of a user or group from a domain is always based on the SID of the domain, and uniquely identifies the user or group. ACLs are placed on a resource to indicate which users and groups are permitted to access the resource, and what level of access the users and groups are allowed. When a user attempts to access the resource, Windows compares the list of SIDs in the ACL to the list of SIDs that identify the user and his or her group memberships, and grants or denies access as appropriate.
When a user logs on to a domain, the user's account SID and group membership SIDs are determined by a domain controller in the user's account domain. The SID of the trusted domain, the relative ID (RID) of the user's account, the RID of the user's primary group, and the SIDs of all other group memberships are combined into an authorization data structure and passed to the requesting computer. If the authenticating domain controller is running Windows 2000, it also checks to determine if the user has any SIDs in his or her SIDHistory attribute and includes those SIDs in the authorization data.
If the computer that is requesting user authentication is in a different domain from the user's account, authentication occurs by using a trust. Trust is created between Windows NT-based or Windows 2000-based domains to simplify the user's authentication experience--especially by enabling single sign-on. When one domain trusts another, it means that the trusting domain allows the trusted domain to authenticate the users (or computers) whose accounts it manages. During authentication, the computer in the trusting domain accepts the authorization data that is provided by the trusted domain controller. There is no way for the computer that is requesting authentication to determine the validity of the authorization information, so it accepts the data as accurate based on the existence of the trust relationship.
A vulnerability exists because the trusting domain does not verify that the trusted domain is actually authoritative for all the SIDs in the authorization data. If one of the SIDs in the list identifies a user or security group that is not in the trusted domain, the trusting domain accepts the information and uses it for subsequent access control decisions. If an attacker were to insert SIDs into the authorization data at the trusted domain, he or she could elevate his or her privileges to those that are associated with any user or group, including the Domain Administrators group for the trusting domain. This would enable the attacker to gain full Domain Administrator access on computers in the trusting domain.
Exploiting this vulnerability would be a challenge. At a minimum, an attacker would need administrative privileges on the trusted domain, and the technical wherewithal to modify low-level operating system functions and data structures. Windows 2000 provides a mechanism for introducing additional SIDs into authorization data, known as SIDHistory. However, there is no programming interface that would allow an attacker--even with administrative rights--to introduce a SID into the SIDHistory information; instead, an attacker would need to perform a binary edit of the data structures that hold the SIDHistory information. To counter these potential attacks, Microsoft has added a feature called SID filtering to Windows NT 4.0 and Windows 2000. With SID filtering, an administrator can cause the domain controllers in a given domain to "quarantine" a trusted domain. This would cause the domain controllers in the trusting domain to remove all SIDs that are not relative to the trusted domain from any authorization data that is received from that domain. Quarantining is performed from the trusting domain, and is done on a per-domain basis.
SID filtering blocks Windows 2000 transitive trust. If a quarantined domain is located in the trust path between two domains, users from domains on the other side of the quarantined domain cannot access resources in the quarantining domain. For this reason, quarantined domains should be leaf domains, their child domains should be only resource domains that contain no user accounts, or the quarantined domain should be in a separate forest.
A Windows 2000 administrator should not use the SID filtering feature to create a "restricted-access" domain within a forest. The recommended quarantine scenario is to quarantine only domains in separate forests. A trust should be established from the domain that is to be protected to the domain that is to be quarantined, and then the trusting domain should be configured to filter the SIDs from the trusted domain.
Microsoft recommends that you do not use this SID filtering between domains in the same forest because it disrupts the default trust and authentication behavior of a forest, including intra-forest replication, and is likely to lead to problems with programs that might be difficult to troubleshoot. This article contains a list programs and functionality that are known to malfunction in SID filtering environments. Do not use restricted access domains and follow the recommendations that are listed above if you need these programs or functionality. Microsoft cannot provide workarounds for these issues.
To resolve this problem, obtain Windows 2000 Security Rollup Package 1 (SRP1). For additional information about SRP1, click the article number below to view the article in the Microsoft Knowledge Base:
311401 Windows 2000 Security Rollup Package 1 (SRP1), January 2002The English version of this fix should have the following file attributes or later:
Date Time Version Size File name ----------------------------------------------------------------- 08-Oct-2001 19:13 5.0.2195.4472 123,664 Adsldp.dll 08-Oct-2001 19:13 5.0.2195.4308 130,832 Adsldpc.dll 08-Oct-2001 19:13 5.0.2195.4016 62,736 Adsmsext.dll 08-Oct-2001 19:13 5.0.2195.4384 364,816 Advapi32.dll 08-Oct-2001 19:13 5.0.2195.4141 133,904 Dnsapi.dll 08-Oct-2001 19:13 5.0.2195.4379 91,408 Dnsrslvr.dll 08-Oct-2001 19:19 5.0.2195.4411 529,168 Instlsa5.dll 08-Oct-2001 19:13 5.0.2195.4437 145,680 Kdcsvc.dll 04-Oct-2001 21:00 5.0.2195.4471 199,440 Kerberos.dll 04-Sep-2001 09:32 5.0.2195.4276 71,024 Ksecdd.sys 27-Sep-2001 15:58 5.0.2195.4411 511,248 Lsasrv.dll 128-bit 06-Sep-2001 18:31 5.0.2195.4301 507,152 Lsasrv.dll 56-bit 06-Sep-2001 18:31 5.0.2195.4301 33,552 Lsass.exe 27-Sep-2001 15:59 5.0.2195.4285 114,448 Msv1_0.dll 08-Oct-2001 19:14 5.0.2195.4153 312,080 Netapi32.dll 08-Oct-2001 19:13 5.0.2195.4357 370,448 Netlogon.dll 08-Oct-2001 19:13 5.0.2195.4464 912,656 Ntdsa.dll 08-Oct-2001 19:13 5.0.2195.4433 387,856 Samsrv.dll 08-Oct-2001 19:13 5.0.2195.4117 111,376 Scecli.dll 08-Oct-2001 19:13 5.0.2195.4476 299,792 Scesrv.dll 29-May-2001 07:41 5.0.2195.3649 5,632 Sp2res.dll 08-Oct-2001 19:13 5.0.2195.4025 50,960 W32time.dll 01-Aug-2001 21:44 5.0.2195.4025 56,592 W32tm.exe 08-Oct-2001 19:13 5.0.2195.4433 125,712 Wldap32.dllNOTE: Because of file dependencies, this hotfix requires Microsoft Windows 2000 Service Pack 2.
Microsoft has confirmed that this problem may cause a degree of security vulnerability in Microsoft Windows 2000.
For more information on this vulnerability, see the following Microsoft Web site:
Configuring SID FilteringYou can configure SID filtering with the updated Windows 2000 Service Pack 2 (SP2) version of the Netdom.exe utility on Windows 2000-based domains. For SID filtering to work properly, SP2 must be installed on every domain controller in the trusting domain (the domain that is quarantining another domain). The updated version of Netdom.exe is included in the Support Tools folder on the SP2 CD-ROM, or you can download it from the Microsoft Web site. A /filtersids switch has been added to this version of Netdom.exe to configure SID filtering.
For Windows 2000-based domains, to quarantine a domain, use the following command once on one domain controller in the domain (in this example, the RESDOM domain is filtering the ACCDOM domain):
netdom trust RESDOM /D:ACCDOM /UD:ACCDOM\Administrator /PD:adminpwd /UO:RESDOM\Administrator /PO: adminpwd /filtersids:yesThe related command to disable SID filtering is:
netdom trust RESDOM /D:ACCDOM /UD:ACCDOM\Administrator /PD:adminpwd /UO:RESDOM\Administrator /PO:adminpwd /filtersids:noTo verify the SID filtering settings on a domain, use this command:
netdom trust RESDOM /D:ACCDOM /UD:ACCDOM\Administrator /PD: adminpwd /UO:RESDOM\Administrator /PO:adminpwd /filtersidsTypical Active Directory replication causes the setting to be propagated to all domain controllers in the domain.
Authentication and Auditing ChangesRefer to the online Help in Windows 2000 for information about how to configure auditing in Windows 2000.
When a trust is established, the trusting domain creates and stores a data structure called a Trusted Domain object (TDO) that contains the SID of the trusted domain and other information about the trust. When SID filtering is enabled for a trusted domain, authentications to that domain do not succeed if the authorization data presents a domain SID that does not match the SID in the trusting domain's TDO for the quarantined domain. This circumstance can occur only if the authorization data was altered. If authentication does not succeed in this manner and logon or logoff auditing is enabled, an event is generated in the event log on the domain controller that is processing the authentication request in the trusting domain.
SP2 includes a new security audit event with event ID 548 for NTLM authentication, and adds a new failure code (0xC000019B) to event ID 677 during Kerberos authentication. These are logon or logoff failure events that are generated when the domain SID is "spoofed." The following sample entries demonstrate these events.
During NTLM authentication:
Event Type: Failure Audit Event Source: Security Event Category: Logon/Logoff Event ID: 548 Date: Event date Time: Event time User: NT AUTHORITY\SYSTEM Computer: Name of the computer where the event is logged Description: Logon Failure. Reason: Domain sid inconsistent User Name: Name of the user being authenticated Domain: Name of the Quarantined Domain Logon Type: 3 Logon Process: NtLmSsp Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Workstation Name: Name of the client computerDuring Kerberos authentication:
Event Type: Failure Audit Event Source: Security Event Category: Account Logon Event ID: 677 Date: Event date Time: Event time User: NT AUTHORITY\SYSTEM Computer: Name of the computer where the event is logged Description: Service Ticket Request Failed: User Name: Name of the user being authenticated User Domain: Name of the user's Domain Service Name: Full qualified name of the Quarantined Domain Ticket Options: 0x0 Failure Code: 0xC000019B Client Address: 127.0.0.1 Event Type: Failure Audit Event Source: Security Event Category: Logon/Logoff Event ID: 537 Date: Event date Time: Event time User: NT AUTHORITY\SYSTEM Computer: Name of the client computer Description: Logon Failure: Reason: An unexpected error occurred during logon User Name: Name of the user being authenticated Domain: Name of the user's Domain Logon Type: 2 Logon Process: User32 Authentication Package: Negotiate Workstation Name: Name of the client computer
Limitations of SID FilteringThere are three potential drawbacks associated with SID filtering that could potentially prevent some users from gaining access to resources for which they are authorized:
- SID filtering and SIDHistory are mutually exclusive mechanisms. If SID filtering is in effect on a domain, it filters any SIDHistory information in incoming authorization data from quarantined domains.
- SID filtering can block the single sign-on benefits of transitive trust in Windows 2000. For example, assume that domain A trusts domain B, and domain B trusts domain C. Typically, in Windows 2000, a user from domain C could gain access to resources in domain A because domain A transitively trusts domain C. However, if domain A has SID filtering in effect for domain B, it would no longer allow domain B to vouch for a user from domain C, because domain B is not authoritative for SIDs in domain C.
- SID filtering filters SIDs that are associated with a user's membership in universal groups if the groups are not maintained in the user's account domain.
Incompatible Programs and FeaturesThe following programs and Windows 2000 features are known to be incompatible with SID filtering:
- Universal group membership for all universal groups that are not in the user's account domain
- Microsoft Exchange 2000 features that rely on universal groups
- SIDHistory for migrated accounts
- Transitive trust does not work properly
- Active Directory replication--for this reason in particular, SID filtering should not be used between domains in the same forest. SID filtering should be used only to filter on external trusts.
265173 The Datacenter Program and Windows 2000 Datacenter Server productFor additional information about how to install multiple hotfixes with only one reboot, click the following article number to view the article in the Microsoft Knowledge Base:
296861 How to install multiple Windows updates or hotfixes with only one reboot
Article ID: 289243 - Last Review: 12/06/2015 00:35:21 - Revision: 5.0
- kbnosurvey kbarchive kbbug kbfix kbsecbulletin kbsechack kbsecurity kbsecvulnerability kbwin2000presp3fix KB289243