Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
|
|
|
|
|
|
|
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
|
|
|
|
Report a vulnerability that you have found to SecurityTracker
|
|
|
|
Want to learn about SecurityTracker? We've got answers to frequently asked questions right here
|
|
|
|
|
|
|
|
|
|
|
Microsoft Windows NT 4.0 and Windows 2000 Domain Controllers May Give Elevated Privileges to Remote Users Who Are Valid Administrators on Other Trusted Domains
|
Date: Jan 31 2002
|
Impact: Root access via network, User access via network
|
Fix Available: Yes
Vendor Confirmed: Yes
|
Version(s): Windows NT 4.0, Windows 2000
|
Description: Microsoft reported a vulnerability in their Windows NT and Windows 2000 Domain Controller software. A remote user with administrative
privileges on a domain controller can gain elevated privileges on another domain that trusts the user's domain controller.
Microsoft reports that the domain controller software fails to validate all Security Identifiers (SIDs) supplied by a remote trusted
domain. A user who is a valid administrator on a trusted domain can reportedly insert SIDs of his choice into the domain controller's
authorization data to obtain the privileges associated with a user in another domain that trusts his domain.
As reported by Microsoft,
when a user in a trusted domain requests access to a resource in a different trusting domain (where the "trusting" domain trusts
the "trusted" domain), the trusted domain will supply a list of SIDs that represent authorization data regarding the the user's
identity and group memberships. This information is used by the trusting domain to determine whether to grant the user's request
for resource access.
It is reported that the trusting domain does not verify that the trusted domain is a valid authority for
all of the SIDs listed in the authorization data. So, a user who is an administrator on a trusted domain can add a SID to his domain
controller for a user or security group not in that domain, and the trusting domain will accept the data as valid.
Microsoft
notes that this is a difficult exploit that requires technical knowledge to create and install operating system level code to inject
the SIDs -- there is apparently no easy mechanism for an administrator to inject false SIDs.
|
Impact: A remote user with valid administrative privileges on one domain controller can gain elevated privileges on a different domain that
trusts the user's domain controller. These privileges can reportedly be associated with any user or group, including the Domain
Administrators group for the trusting domain.
Microsoft has assessed the impact as a "moderate" risk for Intranet servers and
a "low" risk for Internet servers.
|
Solution: Microsoft has issued a patch. However, there are some apparently significant considerations to be made before installing the patch
and making the appropriate configuration. See the caveats and descriptions provided by Microsoft in their full advisory, available
at the Vendor URL.
For Windows NT 4.0 Server and Windows NT 4.0 Server, Enterprise Edition, the patch is included in the Windows
NT 4.0 Security Roll-up Package, available at:
http://www.microsoft.com/downloads/release.asp?ReleaseID=31240
For Windows
2000 Server and Advanced Server, this patch is included in Windows 2000 Security Roll-up Package 1, available at:
http://www.microsoft.com/windows2000/downloads/critic
al/q311401/default.asp
For Microsoft Windows 2000 Datacenter Server, the patches are reportedly hardware-specific and available
from the original equipment manufacturer.
Microsoft reports that the Windows NT 4.0 Security Roll-up Package can be installed
on systems running SP6a and that the Windows 2000 Security Roll-up Package 1 can be installed on systems running Windows 2000 SP2.
The
vendor reports that the fix for Windows 2000 will be part of the future Windows 2000 SP3 release.
This patch supercedes several
earlier patches. For the full list, see the Vendor URL.
Microsoft has issued warnings regarding the mechanism designed to fix
this vulnerability. Please read the vendor's advisory carefully. In summary, "SID Filtering" can be installed on a "trusting"
domain controller and configured for a specific trusted domain. When this occurs, the trusting domain will apparently check all
incoming SIDs from the specified trusted domain and will remove any SIDs that don t belong to the trusted domain. Note that SID
Filtering is *not* enabled by default with the patch.
For details on enabling and configuring SID Filtering (using a registry
entry), see Microsoft Knowledge Base article Q289243.
It is reported that SID Filtering may screen out legitimate SIDs in certain
cases (described in the vendor advisory), so this option should be carefully considered in advance of implementation.
|
Vendor URL: www.microsoft.com/technet/security/bulletin/MS02-001.asp (Links to External Site)
|
Cause: Authentication error
|
Underlying OS: Windows (NT), Windows (2000)
|
Reported By: secnotif@microsoft.com
|
Message History:
None.
|
Source Message Contents
|
Date: Wed, 30 Jan 2002 18:51:12 -0800
From: secnotif@microsoft.com
Subject: Microsoft Security Bulletin MS02-001
|
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: Trusting Domains Do Not Verify Domain Membership of
SIDs in Authorization Data
Date: 30 January 2002
Software: Windows NT 4.0, Windows 2000
Impact: Privilege Elevation
Max Risk: Moderate
Bulletin: MS02-001
Microsoft encourages customers to review the Security Bulletin at:
http://www.microsoft.com/technet/security/bulletin/MS02-001.asp.
- ----------------------------------------------------------------------
Issue:
======
Trust relationships are created between Windows NT or Windows 2000
domains to allow users in one domain to access resources in other
domains without requiring them to authenticate separately to each
domain. When a user in a trusted domain requests access to a resource
in a trusting domain, the trusted domain supplies authorization data
in the form of a list of Security Identifiers (SIDs) that indicate
the user's identity and group memberships. The trusting domain uses
this data to determine whether to grant the user's request.
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 identified a
user or security group that is not in the trusted domain, the
trusting domain would accept the information and use it for
subsequent access control decisions. If an attacker inserted SIDs of
his choice into the authorization data at the trusted domain, he
could elevate his privileges to those associated with any desired
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 difficult, and require
administrative privileges on the trusted domain, as well as the
technical wherewithal to modify low-level operating system functions
and data structures.
- Windows NT 4.0 provides no mechanism by which additional
SIDs could be added to authorization data. To exploit the
vulnerability, an attacker would need to develop and
install custom operating system components to add the
SIDs.
- Windows 2000 does provide 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 desired SID into the SIDHistory information;
instead, an attacker would need to perform a binary edit of
the data structures that hold the SIDHistory information.
Microsoft has developed a mechanism called SID Filtering that
eliminates the vulnerability and adds further protection between
trusting domains. When installed and enabled on the domain
controllers of a trusting domain, SID Filtering causes the system to
inspect all incoming authorization data and remove any SIDs that do
not identify a user or security group that is defined in the trusted
domain.
There are, however, tradeoffs associated with using the SID Filtering
mechanism. These are summarized in the FAQ and Caveats sections
below, and are discussed in detail in Microsoft Knowledge Base
article Q289243 and in a technical white paper
(http://www.microsoft.com/windows2000/techinfo/administration/security
/sidfilter.asp) that Microsoft strongly urges administrators to read
before using SID Filtering. This is especially important in the case
of administrators who are in the midst of migrating their networks
from Windows NT 4.0 to Windows 2000.
Mitigating Factors:
====================
- The attacker would need to have domain administrator privileges
in the trusted domain in order to exploit the vulnerability.
- The attacker's domain would need to already be trusted by
the target domain, or the target domain's administrator would
need to approve the establishment of a new trust relationship.
- There is no capability for the attacker to unilaterally
initiate a trust relationship with another domain or cause it
to trust the attacker's domain.
- The attacker would need to modify operating system components
and data.
Risk Rating:
============
- Internet systems: Low
- Intranet systems: Moderate
- Client systems: None
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin at
http://www.microsoft.com/technet/security/bulletin/ms02-001.asp
for information on obtaining this patch.
Acknowledgment:
===============
- Aelita Software (http://www.aelita.com)
- Michel Trepanier of CMT Inc. and Loto-Quebec.
- ---------------------------------------------------------------------
THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS
PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS
ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE
FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL,
CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF
MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION
OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO
THE FOREGOING LIMITATION MAY NOT APPLY.
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1
iQEVAwUBPFif/40ZSRQxA/UrAQGWeQf9FAB4oIyvZg1y5aoD7johLACCZA3I0tW+
N8svEut81YM19csVbt0Ct+KvBT/5ctumQjuaOwzUvaSdoWzWsTharLJnWaJoAmP8
tnJ8HJQqtCLwRkyqzv6g9FUUw7yeD6CXHrZsLTdGy+gHCqEYyDeo2vIsS/mwDQG/
91EZW8AFWM2mmIiKGzk8C3A6DJa8iwyNqHDFld7jI6e7SooT95ZVpsZq1SYicKzD
yj5X1o2S5/9/4Hrt3mZjIQmETPTsXDFD1lWvolDheZ2r+SL2nGnV2lOtiayYFLSQ
MvkmOKBQfus9nXRCsWtte+UjgzXttEVZpT8/42rBYUJOX+vsh/hXXQ==
=7wGB
-----END PGP SIGNATURE-----
*******************************************************************
You have received this e-mail bulletin as a result of your subscription to the Microsoft Product Secu rity Notification Service.
For more information on this service, please visit http://www.microsoft.com/technet/security/notify .asp.
To verify the digital signature on this bulletin, please download our PGP key at http://www.microsoft .com/technet/security/notify.asp.
To cancel your subscription, click on the following link mailto:1_24813_***************************** *******_US@Newsletters.Microsoft.com?subject=UNSUBSCRIBE
to create an unsubscribe e-mail.
To stop all e-mail newsletters from microsoft.com, click on the following link mailto:2_24813_******* *****************************_US@Newsletters.Microsoft.com?subject=STOPMAIL
to create an unsubscribe e-mail. You can manage all your Microsoft.com communication preferences fr om http://www.microsoft.com/misc/unsubscribe.htm
For security-related information about Microsoft products, please visit the Microsoft Security Advis or web site at http://www.microsoft.com/security.
|
|
Go to the Top of This SecurityTracker Archive Page
|