MS02-001: Forged SID could result in elevated privileges in Windows 2000 (289243)

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 "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.

   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
				

   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
				

   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