Microsoft Security Bulletin MS00-095

Technical description:

Three registry keys have default permissions that are inappropriately loose. The keys, and the risk they pose, are as follows:

• The "SNMP Parameters" key, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SNMP\Parameters, provides the SNMP community name and SNMP management station identifiers, if they exist. SNMP community strings may allow either read or read-write access to the SNMP service. If no read-write access strings exist, the user could only use this vulnerability to read information through SNMP that is normally available to local users. If read-write access strings do exist, a malicious user could use this vulnerability to make changes to any system using the same community string for read-write access. It is important to remember that SNMP v1.0 has no security by design, and any user who could monitor network traffic could also obtain the SNMP community strings. SNMP is not installed on Windows NT 4.0 machines by default.
• The "RAS Administration" key, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RAS, provides a way to install third-party RAS products that work with the Windows NT native RAS service. By changing one of the values in this key, it would be possible for a malicious user to specify code of her choice as a third-party management tool. The code would then run in the LocalSystem security context. Although it might be possible to make the needed registry changes remotely, the malicious user's code would need to reside on the affected machine itself. RAS is not installed on Windows NT 4.0 machines by default.
• The "MTS Package Administration" key, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Transaction Server\Packages, includes information about which users are allowed to install and change MTS packages. By adding herself as an MTS manager, a malicious user could gain the ability to add, delete or change MTS packages. Although it might be possible in some cases to make the needed registry changes remotely, the malicious user would still need the ability to log onto the affected machine interactively in order to exercise her new privileges. MTS is not installed on Windows NT 4.0 machines by default.

In addition to correcting the permissions on these keys, the tool also changes the permissions on several other keys that have previously been discussed. Specifically, the tool makes all the changes discussed in Microsoft Security Bulletins MS00-008 and MS00-024.

What's this bulletin about?
Microsoft Security Bulletin MS00-095 announces the availability of a tool that eliminates three security vulnerabilities in Microsoft® Windows NT® 4.0. Microsoft is committed to protecting customers' information, and is providing the bulletin to inform customers of the vulnerabilities and what they can do about them.

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 a 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?
If the affected machine was part of a community, the ability to read the two values in the SNMP Parameters key would let the malicious user 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 would this let the malicious user do? 
The most accurate answer is "it depends". The malicious user would gain whatever privileges SNMP managers within that community have. If, for example, SNMP managers within the community can reconfigure routers, the malicious user could do this too, once she learned the community name and the identifying information for a management station.
Recall that SNMP managers derive their privileges from their knowledge of the community string, which functions like a password, and that different community strings provide different levels of access. The precise damage that the malicious user could do would depend on the community string she could compromise, and the privileges that it grants. For example, if she learned the community name in a community that consisted only of routers and which 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 she change the values of the registry keys in order to create her own community or change an existing one? 
No. The permissions on the registry keys do not, even in their default state, provide write access to the keys.

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:

What is Microsoft doing about this issue?

• Microsoft has delivered a tool that eliminates the vulnerability.
• Microsoft has provided a security bulletin and this FAQ to provide customers with a detailed understanding of the vulnerability and the procedure to eliminate it.
• Microsoft has sent copies of the security bulletin to all subscribers to the Microsoft Product Security Notification Service, a free e-mail service that customers can use to stay up to date with Microsoft security bulletins.
• Microsoft has issued Knowledge Base articles explaining the vulnerability and procedure in more detail.

Where can I learn more about best practices for security?
The Microsoft TechNet Security web site is the best to place to get information about Microsoft security.

How do I get technical support on this issue?
Microsoft Product Support Services can provide assistance with this or any other product support issue.

Download locations for this patch

• Windows NT 4.0 Workstation, Windows NT 4.0 Server, and Windows NT 4.0 Server, Enterprise Edition: http://www.microsoft.com/downloads/details.aspx?FamilyId=8E7C68EE-98BC-440E-A99D-6A97308FDCB0&displaylang=en
• Windows NT 4.0 Server, Terminal Server Edition:http://www.microsoft.com/downloads/details.aspx?FamilyId=2DE21079-468C-4A47-BA65-3D9028558D4A&displaylang=en

  Note: The version of the tool in this bulletin also includes all changes discussed in Security Bulletins MS00-008 and MS00-024.

  Note: This tool may be run on machines running Windows NT 4.0 Service Packs 5 and 6a.