Microsoft KB Archive/289246

= MS02-001: Forged SID Could Result in Elevated Privileges in Windows NT 4.0 =

PSS ID Number: 289246

Article Last Modified on 5/14/2003

-

The information in this article applies to:


 * Microsoft Windows NT Server 4.0 Terminal Server Edition SP4
 * Microsoft Windows NT Server 4.0 Terminal Server Edition SP5
 * Microsoft Windows NT Server 4.0 Terminal Server Edition SP6
 * Microsoft Windows NT Server 4.0
 * Microsoft Windows NT Server 4.0 SP1
 * Microsoft Windows NT Server 4.0 SP2
 * Microsoft Windows NT Server 4.0 SP3
 * Microsoft Windows NT Server 4.0 SP4
 * Microsoft Windows NT Server 4.0 SP5
 * Microsoft Windows NT Server 4.0 SP6a
 * Microsoft Windows NT Server, Enterprise Edition 4.0
 * Microsoft Windows NT Server, Enterprise Edition 4.0 SP4
 * Microsoft Windows NT Server, Enterprise Edition 4.0 SP5
 * Microsoft Windows NT Server, Enterprise Edition 4.0 SP6a
 * Microsoft Windows NT Workstation 4.0
 * Microsoft Windows NT Workstation 4.0 SP1
 * Microsoft Windows NT Workstation 4.0 SP2
 * Microsoft Windows NT Workstation 4.0 SP3
 * Microsoft Windows NT Workstation 4.0 SP4
 * Microsoft Windows NT Workstation 4.0 SP5
 * Microsoft Windows NT Workstation 4.0 SP6a

-



This article was previously published under Q289246



For additional information about this issue in Windows 2000, click the article number below to view the article in the Microsoft Knowledge Base:

289243 MS02-001: Forged SID Could Result in Elevation of Privilege in Windows 2000

IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows Registry



SYMPTOMS
Microsoft Windows NT 4.0 protects system resources with access control lists (ACLs). ACLs are lists of security identifiers (SIDs), and a list 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 it, and what level of access they are allowed. When a user attempts to access the resource, Windows NT compares the list of SIDs in the ACL to the list of SIDs that identify the user and his 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.

When the computer that is requesting user authentication is in a different domain than the user's account, authentication occurs 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 will allow 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 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 inserted SIDs into the authorization data at the trusted domain, the attacker 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.

It is very hard to exploit this vulnerability. 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.

To counter these potential attacks, Microsoft has added a feature called SID filtering to Windows NT 4.0. With SID filtering, an administrator can cause the domain controllers in a given domain to &quot;quarantine&quot; a trusted domain. This causes 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.



CAUSE
When a trust relationship exists between two domains, the trusting domain accepts the SIDs that are specified within authorization data provided by the trusted domain even if the SIDs are from domains other than the trusted one. If an attacker in a trusted domain were able to insert SIDs into authorization data, the attacker could grant himself or herself the privileges that are associated with a user in another domain, including the trusting domain itself.



Windows NT 4.0
To resolve this problem, obtain the Windows NT 4.0 Security Rollup Package. For additional information, click the article number below to view the article in the Microsoft Knowledge Base:

299444 Post-Windows NT 4.0 Service Pack 6a Security Rollup Package (SRP)

The English version of this fix should have the following file attributes or later:   Date      Time    Size     Version        File name     Platform 02/22/01 4:19pm  155,920  4.0.1381.7092  Lsasrv.dll    Intel 02/22/01 4:19pm   10,000  4.0.1381.7092  Lsass.exe     Intel 02/22/01 4:18pm   19,216  4.0.1381.7092  Msaudite.dll  Intel 03/13/01 4:59pm  254,736  4.0.1381.7092  Netapi32.dll  Intel 02/22/01 4:19pm  192,784  4.0.1381.7092  Netlogon.dll  Intel 02/22/01 4:15pm  254,224  4.0.1381.7092  Lsasrv.dll    Alpha 02/22/01 4:15pm   16,144  4.0.1381.7092  Lsass.exe     Alpha 02/22/01 4:14pm   23,312  4.0.1381.7092  Msaudite.dll  Alpha 03/13/01 4:55pm  412,432  4.0.1381.7092  Netapi32.dll  Alpha 02/22/01 4:15pm  313,616  4.0.1381.7092  Netlogon.dll  Alpha NOTE: Because of file dependencies, this hotfix requires Microsoft Windows NT 4.0 Service Pack 6a.

Microsoft Windows NT Server version 4.0, Terminal Server Edition
To resolve this problem, obtain the Windows NT Server 4.0, Terminal Server Edition, Security Rollup Package (SRP). For additional information about the SRP, click the article number below to view the article in the Microsoft Knowledge Base:

317636 Windows NT Server 4.0, TerminalServer Edition, Security Rollup Package



STATUS
Microsoft has confirmed that this problem may cause a degree of security vulnerability in Microsoft Windows NT 4.0 and Windows NT Server version 4.0, Terminal Server Edition.



MORE INFORMATION
WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

Registry Key Modification for the Quarantined Bit
In addition to applying the hotfix, Windows NT 4.0 requires a modification of a registry key to quarantine domains. In addition, you can configure auditing to monitor SIDHistory-related security events:  Use Regedt32.exe to add a new REG_MULTI_SZ value named QuarantinedDomains to the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

 Set the data value of the new QuarantinedDomains value to a sequence of zero, or more, NetBIOS domain names. This new value will be recognized by Netlogon.

NOTES:
 * Use only NetBIOS domain names even if the trusted domain is a Windows 2000-based domain.
 * You quarantine a domain by adding its name to the QuarantinedDomains registry value. You cancel quarantine by removing the domain name.
 * There is no error checking or validation of the names that you enter in the QuarantinedDomains registry value to ensure that they correspond to a currently trusted domain. Any legal string value is allowed. However, any value that is not equal to the name of a trusted domain will be ignored. The net effect is that &quot;SIDHistory&quot; quarantine can only be applied by a trusting domain against a trusted domain.
 * You must manually set or rest the registry value on every domain controller in a domain for consistent behavior.
 * After you set the registry key, you must issue net stop netlogon and net start netlogon commands from a command prompt to make the new registry key values take effect.

Auditing Changes
Please refer to the online Help for information about how to configure auditing in Windows NT 4.0.

This hotfix introduces a new Security Audit event with event ID 548 during NTLM authentication. This is a logon and logoff event that is generated when there is a SID History attack on the domain (that is, when the domain SID is spoofed). These events are logged on the domain controller that is processing the authentication request in the trusting domain. The following events will be generated 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 on which 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:            Type of logon (3=network) Logon Process:         NtLmSsp Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Workstation Name:      Name of the client computer

Additional query words: security_patch kbtsesrp

Keywords: kbbug kbfix kbQFE KB289246

Technology: kbNTTermServ400 kbNTTermServ400sp4 kbNTTermServ400sp5 kbNTTermServ400sp6 kbNTTermServSearch kbWinNT400search kbWinNTS400 kbWinNTS400search kbWinNTS400sp1 kbWinNTS400sp2 kbWinNTS400sp3 kbWinNTS400sp4 kbWinNTS400sp5 kbWinNTS400sp6 kbWinNTsearch kbWinNTSEnt400 kbWinNTSEnt400sp4 kbWinNTSEnt400sp5 kbWinNTSEnt400SP6a kbWinNTSEntSearch kbWinNTSsearch kbWinNTW400 kbWinNTW400search kbWinNTW400sp1 kbWinNTW400sp2 kbWinNTW400sp3 kbWinNTW400sp4 kbWinNTW400sp5 kbWinNTW400SP6a kbWinNTWsearch

-

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

© 2004 Microsoft Corporation. All rights reserved.