|
|
|
|
| |
| Several Windows registry keys come with bad default permissions. These loose registry permissions may enable attackers to change system settings and possibly even manage the machine remotely. |
| |
Credit:
These security problems were discovered by Milan Dadok, Glenn Larsson and Chris Anley.
|
| |
Vulnerable systems:
Microsoft Windows NT 4.0 Server
Microsoft Windows NT 4.0 Server, Enterprise Edition
Microsoft Windows NT 4.0 Server, Terminal Server Edition
Microsoft Windows NT 2000 Professional, Server, Advanced Server (only vulnerable to the SNMP registry problem)
RAS Administration Registry Key
The registry key in Windows NT 4.0 that handles the administration of Remote Access Service (RAS) third-party tools is not properly configured to deny write access to unprivileged users. Such lenient permissions assigned to this particular registry key would allow any user that could log on locally to a system with a RAS server installed to modify the value of the key to an arbitrary DLL file that would be executed upon startup of RAS. The DLL in the RAS registry key is run under LocalSystem privileges. Therefore, the malicious user would be able to perform any action under the LocalSystem security context, which would yield full control over the local machine. The location of the RAS registry key is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RAS.
This vulnerability could be exploited remotely if the Winreg key was enabled to allow remote access to the registry (Winreg is enabled by default).
Note: RAS is not installed by default on Windows NT 4.0.
MTS Package Administration Registry Key
Microsoft Transaction Server (MTS) is the mechanism used by Microsoft Windows NT to handle transactions or MTS packages, which are series of software modules that form a transaction.
The registry key in Windows NT 4.0 that handles the administration of Microsoft Transaction Server (MTS) is not properly configured to deny write access to unprivileged users. Modification rights on this particular registry should only be reserved for administrators. However, any user that is able to log onto a system with MTS installed is able to alter the values for the MTS registry key and its subkeys located at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Transaction Server\Packages.
Among the information stored in the MTS registry key is the list of MTS managers for each MTS package. A malicious user can reconfigure or add new MTS packages to the system by adding his userid to the list of managers of the System Package by modifying values in the MTS registry key.
While adding new MTS packages to be executed under the context of a different account requires the account password and thus a malicious user would have to known the password to execute a new package under a context other than his own, the malicious user could modify an existing MTS package to perform unauthorized actions.
The registry key could be modified remotely if the Winreg key was enabled to allow remote access to the registry (Winreg is enabled by default).
Note: MTS is not installed by default on Windows NT 4.0. MTS is part of the Windows NT 4.0 Option Pack.
SNMP Registry Key Modification
The SNMP service in Windows NT 4.0 and 2000 enables the remote management
of the computer. Loose permissions in the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SNMP\Parameters allow malicious users with access to the registry to read the SNMP community names stored in the ValidCommunities key value. This allows the malicious users to manage the computer via SNMP.
The malicious users could also change the community names by modifying the registry key thus denying authorized users access to the machine via SNMP.
Solution
Microsoft has released a patch that tightens these registry permissions.
Microsoft Windows NT 4.0 Intel:
http://download.microsoft.com/download/winntsp/Patch/Q266794/NT4/EN-US/Q265714i.EXE
Microsoft Windows NT 2000 Intel:
http://download.microsoft.com/download/win2000platform/Patch/Q266794/NT5/EN-US/Q266794_W2K_SP2_x86_en.EXE
Why have three vulnerabilities been addressed in this patch?
The problem underlying all three vulnerabilities is the same - registry values whose default permissions are too permissive. Likewise, the fix for all three is to reset the permissions to an appropriate value. To minimize the number of patches customers need to apply, we have provided a patch that resets all three keys' permissions.
What are the three registry keys?
The keys are:
* The "SNMP Management" key.
* The "RAS Administration" key.
* The "MTS Package Administration" key.
What is the scope of the vulnerability associated with the "SNMP Management" key?
This vulnerability could allow a malicious user to manage or configure devices on the network. The specific privileges she could gain would vary widely from network to network, and would depend on the extent to which Simple Network Management Protocol (SNMP) is used on it. In the worst case, though, the vulnerability could enable her to misconfigure routers and firewalls, change content on web servers and database servers, stop or start services on the local machine, and so forth.
SNMP is, by design, not a secure protocol. Even in the absence of inappropriate registry permissions, a malicious user could still monitor the network and obtain all the information needed to manage SNMP devices on the network. SNMP is not installed on Windows NT 4.0 systems by default.
What is SNMP?
SNMP (Simple Network Management Protocol) allows administrators to remotely manage network devices such as servers, workstations, routers, bridges, firewalls, and so forth. SNMP is an industry-standard protocol, which allows devices made by many different vendors to be managed via the protocol.
How does SNMP work?
The TechNet web site provides a detailed description of how SNMP works in Microsoft networks, but here is a high-level description.
One of the central concepts in SNMP is that of a community - a collection of devices that have common administrators with the same level of privilege. For instance, if there were 10 routers on a network, and three people with approval to manage them, the routers and the users' machines would be part of the same community. If there was an additional user who only had permission to monitor the routers, the routers and this user would need to be members of a separate community. As you can guess, it's not uncommon for a particular device to be a member of many communities.
Every device within a community has a collection of locally-stored information about the community. For instance, each machine must be configured with the community name, which functions basically as a pre-shared password. Also, each machine knows the machines from which SNMP managers may issue commands. When a command arrives from one of those machines, containing the right community name, the device processes the command.
The manager's SNMP software is able to send commands that make sense to the devices by referring to a local database called the MIB (Management Information Base). The MIB contains information specifying exactly how to communicate with each device - what functions to call, how the command information should be passed, etc. By referring to the MIB, the software on the manager's machine (called a management station in SNMP parlance) can issue commands that are meaningful to the devices.
When you say that SNMP can be used to manage devices, what kinds of actions do you mean?
It varies depending on several factors, including the type of device, the level of privilege the SNMP manager has been granted, and other factors. However, here are some examples of management functions that could be performed on various devices.
* Start or stop services on workstations or servers
* Monitor the CPU and memory usage on an application server
* Add, change or delete content on a web server or database server
* Reconfigure a router
* Change a firewall's filtering rules
What's the "SNMP Management" registry key, and what does it do?
The "SNMP Management" key is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SNMP\Parameters. There are two values of interest within this key:
* PermittedManagers, which specifies the IP addresses or the machine names of the management stations for a community.
* ValidCommunities, which specifies all of the communities that the machine belongs to.
What's wrong with the SNMP Management registry key's permissions?
The permissions are too loose. By design, the information in this key should only be accessible to users with administrative privileges on the machine. In reality, though, they allow any user on the machine to view and change them.
What could a malicious user do with this information?
A malicious user could exploit the vulnerability in either of two ways:
* She could add information to these two values in order to create a community consisting solely of the local machine, with herself as the SNMP manager. By doing this, she would gain the ability to manage the local machine.
* If the machine was part of a community, the ability to read the two values in the SNMP Parameters key would let her pose as an SNMP manager. She could spoof the IP address or machine name of a bona fide management station, then supply the community name in order to issue commands to other devices in the community.
What could the malicious user do if she created a community consisting of her local machine?
It would depend somewhat on the particular type of machine she was able to compromise. On a workstation, she might be able to do no more than start and stop services on the machine. On a web server or database server, she might be able to change data on the machine or change who could access the data.
What could the malicious user do if her machine was already part of a community?
As discussed above, the specific management functions that could be performed on a particular network vary widely and depend on a number of factors that are specific to each network. As a result, it isn't possible to say precisely what privileges the malicious user could gain, except to say that she could gain whatever privileges SNMP managers have within the communities that she "hijacked". If she became an SNMP manager in a community that consisted only of routers and only allowed managers to monitor them, the risk posed by the vulnerability would be slight. On the other hand, if the community consisted of web and database servers, and SNMP managers had privileges that allowed them to change content on the servers, the risk could be higher.
Could this vulnerability be remotely exploited?
Before answering this question, we should clarify once again what the vulnerability is. The vulnerability lies in the fact that the malicious user could read or change registry values that contain SNMP information. The vulnerability does not lie in the ability of the malicious user, once she read or changed the information, to manage network devices. By design under SNMP, anyone possessing this information would be authorized to manage the devices.
Whether or not a machine's registry can be remotely accessed or not depends on the setting of registry key called the Winreg key. By default, the Winreg key on a Windows NT 4.0 server is set to prevent remote access. However, on Windows NT 4.0 workstations, the default setting of the Winreg key allows remote access to the registry. The tools provided in Microsoft Security Bulletins MS00-008 and MS00-024 correct this, as does the tool provided here.
How secure is SNMP?
SNMP is, by design, not a secure protocol. The information that's revealed via this vulnerability - community names and the identity of the management stations - travel over the network in plaintext during normal operation of the protocol. As a result, a determined attacker who had the ability to monitor network communications could carry out the very same attacks we've discussed above, even in the absence of this vulnerability.
Is SNMP installed on Windows NT 4.0 machines by default?
No. SNMP is only present on a machine if an administrator has installed it.
What's the scope of the vulnerability associated with the "RAS Administration" registry key?
This is a privilege elevation vulnerability. By changing one of the values in this registry key, a malicious user could log onto an affected machine interactively could cause code of her choice to run on the machine with the privileges of the operating system. This would enable the code to take virtually any action on the machine, including adding, deleting or changing data, reformatting the hard drive, creating local user accounts, and so forth.
Although the vulnerability could be used to gain control of the local machine, it could not be used directly to gain privileges on the domain. In additional, the vulnerability could only be exploited on a machine on which Remote Access Services (RAS) has been installed. As discussed below, this would tend to limit the vulnerability to machines that have been misconfigured, or on which best practices have not been followed.
What's the "RAS Administration" key?
The "RAS Administration" key is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RAS. Its purpose is to allow administrators to install third-party products that extend the functionality of Microsoft's native RAS service.
What's wrong with the key?
The permissions on the key are too loose, and values in this key could be modified by unprivileged users. This poses a security risk because of one of the values that can be specified within the key. If a third-party RAS administration tool has been installed, this value provides the name of a DLL that should be when the tool is started. The too-loose permissions on the RAS Administration key would allow a malicious user to change this value to specify the name of any DLL she wanted.
Why would someone want to surreptitiously install a RAS administration tool on their machine?
The point wouldn't be to install a RAS tool, but rather to use the vulnerability to gain privileges on the machine. The DLL specified in this RAS Administration key runs with LocalSystem privileges - that is, it runs as part of the operating system on the local machine. By specifying code of her choice via the RAS Administration key, the malicious user could make that code run as part of the operating system.
It's important to note, though, that there would be some constraints on the code. The malicious user would need to install a DLL whose entry points matched those of a bona fide RAS administration tool. This means that the code would need to be developed especially for this purpose.
What could a malicious user use this vulnerability to do?
If a malicious user exploited this vulnerability, she could gain complete control over the local machine. She could do literally anything she wanted on the machine, from changing data, to reformatting the hard drive, to installing new system components, to creating local users.
Could this vulnerability be remotely exploited?
In certain cases, it might be possible for a malicious user to change the registry values remotely. Remote access to a machine's registry is regulated via the Winreg key. By default, the Winreg key on a Windows NT 4.0 server is set to prevent remote access. However, on Windows NT 4.0 workstations, the default setting of the Winreg key allows remote access to the registry. The tools provided in Microsoft Security Bulletins MS00-008 and MS00-024 correct this, as does the tool provided here.
However, even if the malicious user could change the registry values remotely, it still wouldn't be enough to allow her to run code. The DLL that's specified via the registry value must reside on the local machine -- that is, the one the malicious user attacked -- so she would need a means of loading her code onto the machine remotely. Even if she could do this, she would need a way to convince the operator to start the RAS administration tool and make the code run.
Would the vulnerability allow the malicious user to gain additional privileges on the domain?
No. The code would only run on the local machine. There is no capability to directly gain additional privileges on the domain via this vulnerability.
Would RAS have to be installed on the machine in order to exploit this vulnerability?
Yes. The key does not exist unless RAS has been installed on the machine. RAS is not installed by default on either Windows NT 4.0 workstation or Server. This is a significant point, because it means that the vulnerability could likely only occur in one of three scenarios, each of which is clearly already contrary to best practices:
* It could occur if an unprivileged user's machine was being used as a RAS server. Clearly, this would be a bad idea - the user could conduct a denial of service attack simply by unplugging the modem.
* It could occur if an unprivileged user could log onto a RAS server interactively. However, critical servers should always be physical protected, and only administrators should be allowed to log onto them.
* It could occur if an unprivileged user was able to install RAS on her machine as a prelude to exploiting the vulnerability. However, administrative privileges are required in order to install RAS, so if the user could do this, she would already have complete control over the machine.
What's the scope of the vulnerability associated with the "MTS Package Administration" registry key?
This vulnerability could enable a malicious user to install new Microsoft Transaction Server (MTS) packages on a machine, or alter ones that are already present on a Windows NT 4.0 machine. If she could log onto a business-critical machine interactively, she could change the business logic on it in any desired way. MTS is not installed by default on Windows NT 4.0.
What is MTS?
MTS is Microsoft Transaction Server. However, before discussing MTS, we should define what's meant by a transaction.
A transaction is an atomic unit of work - that is, it's a unit of work that's carried out all at once or not at all. A transaction also either succeeds or fails - and if it fails, the system must be restored to the same state it was in prior to attempting the transaction. An example of a transaction is a money transfer between bank accounts. Such a transfer would consist of a withdrawal from account #1 and a deposit to account #2. However, the withdrawal should only happen if the corresponding deposit also happens - that is, the transfer must be an atomic operation - and, if the deposit fails, the withdrawal should be rolled back.
MTS is a technology that supports the development and use of transaction-based components in Windows server products. It allows an administrator to create MTS packages, which are groups of software modules that operate together as a transaction. The administrator specifies the software components, the order in which they should process, what should be done in the event that the transaction fails, and other parameters.
What is the "MTS Package Administration" key?
The "MTS Package Administration" key is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Transaction Server\Packages. This key, and its subordinate keys, provide many of the operating parameters for the transaction packages on the machine.
What's wrong with the MTS Package Administration key?
The permissions on it are too loose. By design, a user should need administrative privileges to modify the values under this key. In reality, though, the permissions on this key would allow any user who could log onto a machine interactively to change the settings.
Among the values stored in this key is the list of MTS managers for each MTS package on the machine. In particular, a special package called the System Package is present anytime MTS is installed on a machine, and the managers for this package can, by design, manage all MTS packages on the machine. By adding her own userid to the list of managers on the System Package, a malicious user could gain the ability to reconfigure any MTS package on the machine, or to add new ones.
What would this enable a malicious user to do?
Let's start with what it would not allow her to do. It would not give her a means by which to run code on her own machine in a highly-privileged security context. When installing a new package, the MTS manager must provide the userid and password for the account under which the package will run. As a result, any code the malicious user introduced onto the machine would still only be able to run in the context of her own account or another account whose credentials she already knew. To put it another way, the malicious user could only make a package run as, say, Administrator, if she already knew the Administrator password - in which case it would be easier to just log on as Administrator.
The risk this vulnerability poses is that the malicious user could exploit it to change existing MTS packages on a machine. For example, if she had the ability to interactively log onto a server that processes payroll data, it could be possible for her to replace an existing MTS packages with one that would, for instance, send a penny from every employee's paycheck to her bank account. However, it should be stressed that best practices strongly recommend against allowing unprivileged users to log onto critical servers interactively.
Could this vulnerability be remotely exploited?
In certain cases, it might be possible for a malicious user to change the registry values remotely. Remote access to a machine's registry is regulated via the Winreg key. By default, the Winreg key on a Windows NT 4.0 server is set to prevent remote access. However, on Windows NT 4.0 workstations, the default setting of the Winreg key allows remote access to the registry. The tools provided in Microsoft Security Bulletins MS00-008 and MS00-024 correct this, as does the tool provided here.
However, even if the malicious user could change the registry values remotely, it still wouldn't be enough to allow her to add or change MTS packages. MTS Explorer, the tool that's used to manage MTS packages, only runs on the local machine. So, even if she managed to add herself as an MTS manager, she still would need the ability to log onto the target machine in order to actually use her newly-acquired privileges.
Is MTS installed by default?
No. MTS ships as part of the Windows NT 4.0 Option Pack. Only an administrator can install MTS.
What does the tool do?
The tool sets the proper permissions on the registry keys discussed here. In addition, it also corrects the inappropriate permissions discussed in Microsoft Security Bulletins MS00-008 and MS00-024.
Where can I get the tool?
The download location for the tool is provided in the "Patch Availability" section of the security bulletin.
How do I run the tool?
The tool can be run interactively or from a script, against either the local machine or a remote one. The usage is:
regacl40 [-v ] [-m remotecomputername]
* If -v is specified, information is returned regarding the processing of each key.
* If -m is specified, a remote computer name must be provided on the command line. You must currently be logged in to an account that has administrative privileges on the remote machine, or you must have previously established a session with the target machine under such an account. This can be done, for example, by "net using" to IPC$ and providing the proper credentials.
Do I ever need to re-run the tool?
You only need to re-run the tool if you perform an operation that resets any of the permissions on one of the affected registry keys.
How can I tell if the tool ran correctly?
If the verbose option (-v) is used, the tool will indicate whether each individual key was secured successfully. In addition, the tool will provide a return code of 1 if any key could not be set, or 0 otherwise. You can also manually verify that the tool ran correctly by using regedt32 and verifying that the registry permissions are as shown in the table above.
What permissions are set by the tool?
The tool sets the following permissions on the following keys and their subkeys: Hive Key Permission
Hive: HKEY_LOCAL_MACHINE\SYSTEM\
Key: CurrentControlSet Services\SNMP\Parameters\
Permission: PermittedManagers Administrators, System, Creator Owner: Full
Hive: HKEY_LOCAL_MACHINE\SYSTEM\
Key: CurrentControlSet Services\SNMP\Parameters\
Permission: ValidCommunities Administrators, System, Creator Owner: Full
Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: \Microsoft\RAS
Permission: Administrators, System, Creator Owner: Full
Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: \Microsoft\Transaction Server\Packages
Permission: Administrators, System, Creator Owner: Full
Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: Microsoft\Cryptography\Offload\
Permission: Authenticated Users: Read Administrators, System, Creator Owner: Full
Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: Microsoft\Windows NT\CurrentVersion\AeDebug
Permission: Authenticated Users: Read Administrators, System, Creator Owner: Full
Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: Microsoft\Windows\CurrentVersion\
Explorer\User Shell Folders
Permission: Authenticated Users: Read Administrators, System, Creator Owner: Full
Hive: HKEY_LOCAL_MACHINE\SOFTWARE Microsoft\DataFactory
Permission: Authenticated Users: Read Administrators, System, Creator Owner: Full
Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: CurrentControlSet\Services\W3SVC\
Parameters\ADCLaunch Authenticated Users: Read
Permission: Administrators, System, Creator Owner: Full
Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: CurrentControlSet\Control\SecurePipe Servers\
Permission: winreg Administrators: FullBackup Operators: Read
|
|
|
|
|
|
|
