Registry Access

Updated 2/12/02
CAN 1999-0562
CAN 1999-0589
CVE 2002-0049

Impact

A remote attacker could view arbitrary keys in the registry, which could reveal sensitive configuration information which could be used to plan an attack against the system. Furthermore, if the registry is writable, the attacker could make configuration changes, modify the boot-up process, or change login scripts, thus taking control of the system.

Background

Windows operating systems include a feature known as null sessions. A null session is a way of connecting to a remote Windows workstation or server without any user authentication. A null session grants limited privileges which allow other Windows systems to retrieve certain information which is required for Microsoft networking, but isn't intended to allow any type of access which could be exploited by an attacker.

The Windows registry holds all of the system configuration information about a Windows workstation or server. It is made up of a hierarchy of hives, keys, and values. Different parts of the registry contain settings on different aspects of the machine's configuration, such as network services, boot-up procedures, account information, and security settings.

The Problems

The registry was found to be accessible by a null session. This is caused by the registry being accessible by the Everyone group, the same group into which the null user is placed. As a result, any user with Netbios access to the system could gain access to the registry without needing to provide a login name or password. An insecure default installation or the Exchange 2000 System Attendant (CVE 2002-0049) could cause this vulnerability to occur.

Furthermore, if the registry is writable by the Everyone group, a user who connects through a null session could make arbitrary modifications to the registry, which could lead to complete control of the server by modifying the boot-up procedure or the administrator's log-in settings.

Resolution

This problem can be fixed by making a change to the registry. The permissions on the winreg key determine which users are allowed to access the registry. By denying access to this key by the Everyone group, the registry will not be accessible from a null session.

Use the following steps to restrict access to the registry. Use caution when editing the registry, because an error could leave the computer in an unusable state.

  1. If the server is running Windows NT version 3.51, install Service Pack 4.
  2. Log into the system as administrator.
  3. To edit the registry, type regedt32 at the command prompt.
  4. Highlight the window titled HKEY_LOCAL_MACHINE.
  5. By double-clicking on the folders, navigate down to the following key: 
    SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg
    (If the SecurePipeServers key doesn't exist, create it by choosing Add Key from the Edit menu while Control is highlighted. When prompted for the class, specify REG_SZ. Likewise, if the winreg key doesn't exist, create that also.)
  6. Highlight the winreg key, and choose Permissions from under the Security menu. Grant Full Control only to Administrators. Do not grant any privileges to the Everyone group.
If services which require remote access to the registry, such as Directory Replicator or Spooler, are in use, then exceptions to the above permissions must be made. This can be done using the following steps.
  1. Highlight the winreg key.
  2. From the Edit menu, choose New Key.
  3. Add a new key called AllowedPaths. Leave the class blank.
  4. Highlight the AllowedPaths folder.
  5. From the Edit menu, choose Add Value. Add a value called Machine of type REG_MULTI_SZ. Enter the following data: 
    System\CurrentControlSet\Control\ProductOptions
System\CurrentControlSet\Control\Print\Printers
System\CurrentControlSet\Services\Eventlog
Software\Microsoft\Windows NT\CurrentVersion
System\CurrentControlSet\Services\Replicator
If Microsoft Exchange 2000 is installed on the server, then a patch is also required to fix the remote registry permissions problem in the Exchange System Attendant.

In addition to the above changes, it is also advisable to block access to the Netbios ports at the firewall or gateway router. There is usually no reason why a user outside the local network would have a legitimate need for Netbios access. Netbios runs on ports 135, 137, 138, and 139 (TCP and UDP).

Where can I read more about this?

For more information about restricting registry access, see Microsoft Knowledge Base Article Q153183.

For more information about the vulnerability in Exchange System Attendant, see Microsoft Security Bulletin 02-003.

For more information about null sessions, see SecurityFocus.