[NT] Exchange 2000 System Attendant Incorrectly Sets Remote Registry Permissions
From: support@securiteam.comDate: 02/13/02
- Previous message: support@securiteam.com: "[NT] Internet Explorer and Access Allows Macros to be Executed Automatically"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: support@securiteam.com To: list@securiteam.com Date: Wed, 13 Feb 2002 10:15:00 +0100 (CET)
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -
Exchange 2000 System Attendant Incorrectly Sets Remote Registry
Permissions
------------------------------------------------------------------------
SUMMARY
The Microsoft Exchange System Attendant is one of the core services in
Microsoft Exchange. It performs a variety of functions related to the
on-going maintenance of the Exchange system. To allow remote
administration of an Exchange Server using the Exchange System Manager
Microsoft Management Console (MMC) snap in, the System Attendant makes
changes to the permissions on the Windows Registry to allow Exchange
Administrators to remotely update configuration settings stored in the
Registry.
There is a flaw in how the System Attendant makes these Registry
configuration changes. This flaw could allow an unprivileged user to
remotely access configuration information on the server. Specifically,
this flaw inappropriately gives the "Everyone" group privileges to the
WinReg key. This key controls the ability of users and groups to remotely
connect to the Registry. By default, only Administrators are given the
ability to remotely connect to the Registry, by granting permissions on
this key.
The flaw does not grant any abilities beyond the ability to connect
remotely. However, an attacker's ability to make changes to the Registry
once they have successfully connected would be dictated by the permissions
on the specific keys within the Registry itself. Thus, while this
vulnerability does not itself give an attacker the ability to change
Registry settings, it could be used in conjunction with inappropriately
permissive registry settings to gain access to, and make changes to a
systems Registry.
DETAILS
Affected software:
* Microsoft Exchange Server 2000
Patch availability:
Download locations for this patch
* Microsoft Exchange Server 2000:
<http://www.microsoft.com/downloads/release.asp?ReleaseID=35462>
http://www.microsoft.com/downloads/release.asp?ReleaseID=35462
Mitigating factors:
* The vulnerability only grants the ability to connect to the Registry
remotely. It does not weaken any other permissions in the Registry.
* An attacker's ability to connect to the Registry remotely requires the
ability to send SMB traffic to and from the target system. Firewalling
best practices recommends closing the ports that NetBIOS and Direct Host
uses (tcp ports 139 and 445)
What's the scope of the vulnerability?
This vulnerability could allow unprivileged users to remotely access
configuration information on an Exchange 2000 server. In the worst case,
this could enable an attacker to change configuration settings on the
server. The vulnerability is subject to several mitigating factors:
* It only provides an attacker with the ability to access the
configuration. The permissions on the specific configuration values would
determine whether it would be possible for the attacker to take any action
on them.
* Normal firewalling practices, if followed, would prevent an attacker on
the Internet from exploiting the vulnerability.
What causes the vulnerability?
The vulnerability results because the Exchange 2000 System Attendant
incorrectly adds the "Everyone group" to the security permissions of the
HKEY_LOCAL_MACHINE
\SYSTEM\\CurrentControlSet\Control\SecurePipeServers\winreg in the
registry.
What is the Exchange 2000 System Attendant?
The System Attendant is one of the core services in Microsoft Exchange. It
performs a variety of functions related to the on-going maintenance and
processing of the Exchange system such as the generation of address lists,
offline address books, and directory lookup facilities.
One of the key functions that the System Attendant performs is to manage
the configuration settings for Exchange servers within an organization. A
system administrator can use the Exchange System Manager Microsoft
Management Console Snap-in to view configuration settings and make
changes. The System Attendant then propagates those configuration settings
to the appropriate Exchange Servers.
What is the Registry?
The Registry is a central repository for configuration information for
Windows and Windows Applications. It provides a single location where
operating system settings (devices information, boot sequence, network
configuration) application settings (tuning information, configuration
parameters), and user settings (user preferences, recently used short
cuts) can all be stored.
How does the Registry secure the information it stores?
Because the Registry stores information that is critical to the stability
and security of the system, it uses a security model to control access to
that information. Because the Registry is organized into a logical "tree
structure" much like the file system, the security model is similar to
that provided by the Windows NT Files System (NTFS). This security model
assigns permissions at each branch of the tree and ends at the actual
value. Permissions can be assigned based on Windows username or group
membership. The permissions govern a user and/or group's ability to view,
add, change, or delete information within the Registry Value. For example,
an administrator may have the ability to view, add, change, or delete
information from the "WinReg" value, but an unprivileged user may have
none or some of those abilities.
What is the WinReg value?
One of the management capabilities that the Registry provides is the
ability to connect remotely from another Windows-based system. To ensure
the security of this feature, this ability has a security mechanism to
ensure that only authorized users can successfully connect remotely to a
system's registry. This mechanism is handled by the so-called WinReg key.
Specifically, this key is found in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\WinReg. The Security permissions on this value define what Users or Groups can successfully connect remotely to the registry.
By default, only Administrators have permissions on this value, and hence
the ability to connect remotely to a machine's registry. All other users
are denied access, and attempts to connect to the machine's registry as a
non-administrator user would fail.
The WinReg key is talked about in greater detail in Microsoft Knowledge
Base article <http://www.microsoft.com/technet/support/kb.asp?ID=153183>
Q153183.
Does the WinReg value control the ability to add, change or delete
information in the Registry?
No. The WinReg Value only controls the ability to successfully connect
remotely to a machine's Registry. In essence, it only controls whether a
user is able to open a specific computer's Registry. The WinReg Value
itself does not control a user's ability to view, add, change, or delete
specific information in the Registry. That is controlled by the individual
permissions within the Registry.
What's wrong with how the Exchange 2000 System Attendant handles the
WinReg Key?
To successfully manage the configuration settings on Exchange Servers, the
System Attendant requires access to the registry so that an Exchange
Administrator can use the Exchange System Manager MMC snap in to view
configurations settings and make modifications.
To allow that access, the System Attendant sets permissions on the
Registry so that the Exchange System Manager can successfully connect.
However, in making this change, the Exchange 2000 System Attendant
incorrectly adds the "Everyone" group to the WinReg key as part of its
configuration settings.
How might an attacker exploit this vulnerability?
An attacker would most likely attempt to exploit this vulnerability by
attempting to connect to the Registry of the intended target across the
network. To succeed, they would have to establish a connection to the
machine's Registry via tcp ports 139 or 445. The Remote Registry Service
would also need to be running in order for this connection to occur.
Could an attacker exploit this vulnerability on the Internet?
As long as firewalling best practices are followed, an attacker could not
exploit this vulnerability from the Internet. Specifically, if SMB and
Direct Host ports are blocked at the firewall, there would be no way for
an attacker to successfully connect to the Registry across the Internet.
What would this vulnerability enable an attacker to do?
Because the WinReg value only controls the ability to access the Registry
remotely, by itself, this vulnerability would only allow an attacker to
remotely connect to the Registry, thereby giving the attacker direct
access to the Registry. In itself, this vulnerability does not affect an
attacker's ability to manipulate the Registry, only to connect to it.
However, it is very important to keep in mind that once an attacker has
gained access to a machine's Registry, his or her actions are constrained
by only the specific permissions on each key, subkey, and value. This
means that if a Registry value had an inappropriately permissive setting,
allowing Everyone Write Access, for example, an attacker could use this
vulnerability to gain access to exploit that permissive setting.
Because a machines specific Registry permissions are a result of software
installed, administrator settings, and security policies as propagated by
the Security Configuration Manager and Active Directory, the exact scope
of an attacker's possible actions varies from machine to machine. In
addition, while unauthenticated users cannot access a machine by default,
because of the disabling of the Guest account discussed above, an
Administrator can choose to enable that account, thus expanding the scope
of the vulnerability.
What does the patch do?
The patch eliminates the vulnerability by correcting the behavior of the
Exchange 2000 System Attendant and preventing it from granting security
permissions on the WinReg value to the Everyone Group.
Does the patch remove the Everyone Group from the WinReg value?
Yes. In addition to changing the behavior of the System Attendant to
ensure that it does not grant "Everyone" permission on the WinReg value,
the patch also removes the "Everyone" group from the WinReg value.
Does the patch make any other changes to the Registry permissions?
No. The patch only removes the group's "Everyone" permissions on the
WinReg key. All other Registry permissions remain intact.
So, does this mean the patch restores the WinReg value's permissions to
the defaults?
Not necessarily. While the patch does remove the "Everyone" group which
the System Attendant incorrectly adds, it makes no other changes. This
means that if an administrator had herself made changes to the WinReg
value's permissions, this tool would preserve those changes.
ADDITIONAL INFORMATION
The information has been provided by <mailto:secure at MICROSOFT.COM>
Microsoft Security Response Center.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: support@securiteam.com: "[NT] Internet Explorer and Access Allows Macros to be Executed Automatically"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
