Microsoft KB Archive/289243

= MS02-001: Forged SID could result in elevated privileges in Windows 2000 =

Article ID: 289243

Article Last Modified on 10/27/2006

-

APPLIES TO


 * Microsoft Windows 2000 Service Pack 1
 * Microsoft Windows 2000 Service Pack 2
 * Microsoft Windows 2000 Advanced Server
 * Microsoft Windows 2000 Advanced Server

-



This article was previously published under Q289243



SYMPTOMS
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 &quot;quarantine&quot; 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 &quot;restricted-access&quot; 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.



RESOLUTION
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 2002

The 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.dll NOTE: Because of file dependencies, this hotfix requires Microsoft Windows 2000 Service Pack 2.



STATUS
Microsoft has confirmed that this problem may cause a degree of security vulnerability in Microsoft Windows 2000.



MORE INFORMATION
For more information on this vulnerability, see the following Microsoft Web site:

http://www.microsoft.com/technet/security/bulletin/MS02-001.mspx

Configuring SID Filtering
You 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:yes

The related command to disable SID filtering is:

netdom trust RESDOM /D:ACCDOM /UD:ACCDOM\Administrator /PD:adminpwd /UO:RESDOM\Administrator /PO:adminpwd /filtersids:no

To 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 /filtersids

Typical Active Directory replication causes the setting to be propagated to all domain controllers in the domain.

Authentication and Auditing Changes
Refer 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 &quot;spoofed.&quot; 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 computer During 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 Filtering
There 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 Features
The 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.

For additional information about how to obtain a hotfix for Windows 2000 Datacenter Server, click the following article number to view the article in the Microsoft Knowledge Base:

265173 The Datacenter Program and Windows 2000 Datacenter Server product

For 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

Additional query words: security_patch kbWin2000srp1

Keywords: kbbug kbfix kbwin2000presp3fix kbsecvulnerability kbwin2000sp3fix kbsecurity kbsecbulletin kbsechack KB289243

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.