Best Practices for Mitigating RPC and DCOM Vulnerabilities

Article
04/24/2009

This white paper is being made available to assist system administrators and technical personnel in preventing damage caused by an exploit for vulnerabilities in the RPC and DCOM sub-systems in Microsoft’s operating systems. Several such vulnerabilities have been announced in Microsoft security bulletins MS03-026 and MS03-039. The vulnerabilities affect most currently supported Microsoft operating systems. However, this paper is primarily geared to technical personnel supporting organizational networks. Consumers are encouraged to go to www.microsoft.com/protect to get information on the three steps they can follow to help protect themselves from this and other threats.

Where Can I Get the Patch

Considering the importance of this issue, Microsoft highly encourages customers to install the necessary patches as soon as possible. While some mitigation can be performed to prevent exploitation of a vulnerable system, Microsoft highly recommends that all systems be patched as soon as feasible. The most recent patches are available on Microsoft Update (https://update.microsoft.com/microsoftupdate/) and as follows:

Most customers have the 32-bit edition of the operating system. If you are unsure which version you have, try the patch for the 32-bit edition first.

Background
On July 16, 2003, Microsoft released a patch for a buffer overflow vulnerability in a component of the Distributed Component Object Model (DCOM) service on several Microsoft operating systems through Microsoft Security Bulletin MS03-026. On September 10, 2003, Microsoft released MS03-039, announcing the availability of patches for additional security vulnerabilities in the DCOM activation routines. The patches released in MS03-039 supersede the patches released in MS03-026, and should be used instead of those patches. Please note that a system patched with the patches issued in MS03-026 is still vulnerable to the vulnerabilities announced in MS03-039.

While the patches are effective in eliminating all known vulnerabilities in DCOM, Microsoft is very concerned about the possibly large numbers of unpatched systems that could remain vulnerable. On July 25, 2003 several hacker organizations released exploit code for the vulnerability announced in MS03-026 onto the Internet. It is expected that sample exploit code will be released for the issues in MS03-039 shortly after the announcement of the patches. Publicly available exploit code makes it much easier for attackers to craft fully functional worms and other exploits, and therefore greatly increases the urgency with which the patches need to be installed. While many of the sample programs for exploiting this vulnerability will probably be nonfunctional or Trojan horse tools that are meant to compromise the local computer they are executed from instead of an arbitrary remote victim, some of these tools are may become functional as broad attack vehicles. Such a fully functional exploit code could be used to completely compromise a target system or network. It is therefore imperative that systems are protected as soon as possible.

Problem Description

The Remote Procedure Call (RPC) services on Microsoft Windows systems are used to provide seamless communication between both local and remote processes. RPC is used to abstract the implementation details of the network from the programmer, allowing the programmer to focus on the implementation of the program instead of the details of the network. RPC provides a communications platform for many different services, including DCOM. Buffer overflow vulnerabilities were discovered in the DCOM implementation in most versions of Windows. Specifically, the vulnerability is in the RPCSS activation interfaces of DCOM components. These buffer overflows are exploitable in that they can be used to execute arbitrary code if an appropriate exploit is created. Such exploits are generally not trivial to write. However, several exploits are currently available for at least one of these vulnerabilities. The Blaster worm, for example, exploited one of these vulnerabilities.

What Is a Buffer Overflow

A buffer overflow is a programmer’s mistake that can stem from several different problems. As the name implies, the core issue is that a program tries to store more data in a buffer than the buffer was designed to hold. This mistake can take many different forms. While some of the constructs that cause this type of problem are obvious, others can be extremely hard to find.

To exploit a buffer overflow, an attacker would have to create a specially crafted message that causes more data to be stored in a buffer than the buffer was designed to hold. The excess data ends up overwriting various other portions of memory. If this portion of memory contains instructions to be executed, the computer will try to interpret the data sent by the attacker as instructions and execute them. In some cases, it is possible to overwrite the buffer with data that is actually executable program code, causing the computer to execute arbitrary code. This is known as an "exploitable" buffer overflow. The buffer overflows patched in MS03-026 and MS03-039 are exploitable buffer overflows.

Which Systems Were Tested

Microsoft tests all currently supported operating systems for every reported security vulnerability. The following systems were tested:

Windows Server 2003 Gold
Windows Server 2003 64-bit Edition
Windows 2000 Service Pack 4
Windows 2000 Service Pack 3
Windows 2000 Service Pack 2
Windows XP Service Pack 1
Windows XP 64-bit Edition, Version 2003
Windows XP Gold
Windows XP 64-bit Edition, Version 2002
Windows NT 4.0 Server Service Pack 6a
Windows NT 4.0 Workstation Service Pack 6a
Windows NT 4.0 Terminal Services Edition

"Gold" in this case refers to the original release of a product, without any service packs.

Note that both Windows 2000 Service Pack 2 and Windows NT Workstation Service Pack 6a have reached their end of life. However, due to the nature of this vulnerability, the fact that the end-of-life occurred very recently, and the number of these systems currently in active use, Microsoft has decided to make an exception for these vulnerabilities on these two platforms. We do not anticipate doing this for future vulnerabilities, but reserve the right to produce and make available patches when necessary. Users who require patches for products that are out of support may be able to obtain such patches through a support contract. Please contact your Microsoft Product Support Services representative for more information. It should be a priority for customers with existing installations on those platforms to migrate to supported platforms to prevent exposure to future vulnerabilities.

In addition to the above products, Windows Me was also tested, and was found to not be vulnerable to this problem. These comprise all the supported versions of Microsoft operating systems. Other, unsupported, versions of the operating systems were not tested, although other versions may also be vulnerable. For more information on Microsoft’s support policy, please refer to the Windows Life Cycle page at https://www.microsoft.com/windows/lifecycle/default.mspx.

What Should Administrators Do

Patch your systems!

By far the most important factor in combating these issues is to patch all vulnerable systems in your environment as soon as possible. While a number of mitigations are available, there is no substitute for installing the patch. Even if a system is not directly connected to the Internet, it could still be vulnerable to attack from otherwise trusted systems. Those systems typically include other hosts on a corporate intranet, hosts dialed in to an organizational network via VPN or dial-in, and any other host that can get behind the firewall(s) shielding a network from the Internet. In addition, mitigations, such as disabling RPC and/or DCOM on an intranet severely, disrupts many features and prevents some parts of the system from operating normally. Therefore, the preferred approach is to patch all systems as soon as possible. Please refer to the section entitled "Where Can I Get the Patch" for more information on patch availability. However, in those cases where a patch cannot be installed, or where the system gets attacked before it can be patched, please see the Mitigation section for several mitigation strategies.

Detecting Vulnerable Systems

There are several ways to detect whether a system is has been patched the simplest method to assess a single system is to use Microsoft Update, (https://update.microsoft.com/microsoftupdate/). However, for customers with large installations, other methods are more convenient. On large networks where a network management infrastructure is present, administrators can detect the patch by looking for the following registry keys:

Windows Server 2003
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows Server 2003\SP1\KB824146
Windows XP Gold
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP1\KB824146
Windows XP SP1
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP2\KB824146
Windows XP 64-bit Edition, Version 2003
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows Server 2003\SP1\KB824146
Windows 2000
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows 2000\SP5\KB824146
Windows NT 4.0 Workstation, SP6a
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\Current Version\Hotfix\824146
Windows NT 4.0 Server, SP6a
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\Current Version\Hotfix\824146
Windows NT 4.0, Terminal Services Edition, SP6a
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\Current Version\Hotfix\824146

Scanning for Vulnerable Systems

Network administrators can use the KB824146scan.exe scanning tool to identify host computers on their network that do not have the 823980 (MS03-026) or 824146 (MS03-039) security patches installed. For complete information on the tool and to download it, please see Microsoft Knowledge Base Article 827363 at https://support.microsoft.com/default.aspx?scid=kb;en-us;827363&sd=tech

Microsoft previously released the KB823980scan.exe tool. Note that this tool will only scan for systems missing the MS03-026 patch and will incorrectly report that a system with MS03-039 installed is missing MS03-026. Please use the updated KB824146scan.exe tool instead to scan for vulnerable systems.

The KB824146scan.exe tool can scan remote host computers without requiring authentication (that is, you do not have to supply valid credentials on the remote host computer). You can use the tool from a Windows Server 2003-based, Windows XP-based, or Windows 2000-based computer. Note that instead of verifying the registry or the file information for the patch, this tool establishes an RPC session with the destination computer to infer the destination computer's state (patched, unpatched, or unknown). However, the tool does not try to exploit the DCOM vulnerabilities that are addressed in MS03-026 or MS03-039. Therefore, the tool should not cause any instability in destination computers.

The tool is available at: https://www.microsoft.com/downloads/details.aspx?FamilyId=13AE421B-7BAB-41A2-843B-FAD838FE472E&displaylang=en

The Microsoft Baseline Security Analyzer (MBSA) can also be used to scan for systems missing the MS03-0039 patch, as well as many other patches. MBSA requires administrative control on the target, which the KB824146scan.exe tool does not. While Microsoft highly encourages you to use MBSA to assess the general patch state of a network, use this table to decide which tool is preferable to assess whether MS03-039 is installed or not.

	MBSA	KB824146scan.exe
Scans for 824146 (MS03-039)	Yes	Yes
Scans for 823980 (MS03-026)	Yes	Yes
Runs without administrative privileges on the target	No	Yes
Scans for issues other than 824146 and 823980	Yes	No
Scans for some security configuration issues	Yes	No
Scans for weak passwords	Yes	No

For more information or to download MBSA, please see https://www.microsoft.com/technet/security/tools/mbsahome.mspx

Mitigation

As we have stated before, the only foolproof mitigation for this vulnerability is to patch all vulnerable systems. However, until the patches are installed, the vulnerability can be mitigated by blocking the vulnerable ports. The ports that need to be blocked are:

UDP
- 135
- 137
- 138
- 445
TCP
- 135
- 139
- 445
- 593

In addition, if COM Internet Services (CIS) or RPC over HTTP is installed, the vulnerability can be exploited over port 80 and 443. Apart from port 80, these ports should be blocked by any firewall deployment, but it would be prudent at this time to verify that they are indeed blocked by the firewall. Any standard port scanner, such as Microsoft’s PortQry or Foundstone’s SuperScan or ScanLine, can be used to verify this.

To prevent exploitation over port 80, or 443 CIS and RPC over HTTP should be turned off on all systems that do not need it. These services are not installed on any systems by default. For information on how to disable CIS, please see Microsoft Knowledge Base Article 825819. For more information on how to protect a system that requires RPC over HTTP, but not DCOM see the section on Protecting Systems That Require RPC Over HTTP But Not DCOM

Why a Network Firewall May Not Provide Complete Protection

A network firewall that shields a network from the Internet may not completely prevent attacks against these vulnerabilities. The reason is that systems are frequently moved between the protected network and an unprotected network. For example, many employees now carry their laptop computers home with them and then connect them to a cable modem or DSL line. Once connected to such a network, these systems are outside the protection of the organization’s firewall and may be attacked. When a compromised system is then reconnected to the protected network, it will spread the worm on the protected network in spite of the firewall blocking external attacks. In addition, e-mail borne viruses could exploit this vulnerability once they have infected a system inside the firewall. For these reasons, it is absolutely critical that all hosts be protected, and that organizations do not simply rely on firewalls to block the attack.

Host-Based Firewalls

Windows XP and Windows Server 2003 include a built-in firewall that blocks all these ports in its default configuration. To verify that the built-in firewall is turned on and blocking these ports, go to the Network Connections control panel, right-click each network connection in turn, select Properties, and then click the Advanced tab.

Verify that the check box under "Internet Connection Firewall" is selected. Even when a system is on a protected network, turning on the Internet Connection Firewall may be prudent because, while the network may be protected from outsiders, it is not protected from insiders who have already been exploited. Please note that many companies, however, have policies which do not permit use of ICF inside the firewall since it blocks remote management of those systems.

Windows NT 4.0 and Windows 2000 do not have a firewall built in. Most firewall software for home users is available in free or trial versions. Check the following resources for more information on personal firewalls:

McAfee
Symantec
ZoneAlarm Pro (Zone Labs)
Tiny Personal Firewall (Tiny Software)
Outpost Firewall (Agnitum)
Kerio Personal Firewall (Kerio Technologies)
BlackICE PC Protection (Internet Security Systems)

Alternatively, a hardware firewall can be used to protect a small network against attack. Such firewalls are relatively inexpensive and are usually very simple to set up. It is available for purchase in most electronics stores and at Microsoft’s online shop. It is always a prudent security measure to verify that the ports are indeed being blocked after deploying any host-based firewall measure. The port scanners listed above can be used for this verification.

Using IPSec to Block Attacks

On Windows 2000, Windows XP, and Windows Server 2003, it is also possible to use IPSec to block these ports. However, to be effective, a policy would have to block all the vulnerable ports completely or, at least, require security over these ports with hosts that are completely trusted and known to be patched. A policy that trusts all computers in a domain, or that only requests security but does not require it is not going to be entirely effective. The reason is that such a policy would allow infected machines that are incorrectly thought to be safe to communicate unimpeded and thus attack the host that was supposed to be protected.

A simple IPSec policy is available. This policy blocks all traffic over the vulnerable ports. To use this policy, first download and extract the IPSecTools.exe file to a known location on your system. Open Local Security Settings, right-click "IP Security Policies on Local Machine," point to "All Tasks" and select "Import Policies." Then open the DCOM.IPSEC policy, which is one of the files that were extracted from the IPSecTools.exe archive.

Now that the policy has been imported, it must be assigned. Until a policy is assigned, it has no effect. To assign the policy, right-click the desired policy and select "Assign." The DCOM.IPSEC filter includes two policies. One blocks all DCOM traffic except for CIS traffic. The other blocks all DCOM traffic including CIS traffic. Do not use the policy that also blocks CIS traffic on a system that must serve HTTP traffic as it will also block HTTP and HTTPS traffic.

Note that if any other policies are currently assigned, they will be unassigned by this action. If Group Policy has specified an IP Security Policy, Group Policy will override locally assigned policies. In an environment where Group Policy is used to distribute IP Security Policy, the DCOM policy can be distributed via Group Policy to all affected Windows 2000 and higher computers.

For more fine-grained control over the IPSec policy, you may wish use the IPSec_RPC_Blocker tool included with this document. This tool allows you to set up a policy that can block inbound or outbound requests as well as establish some exceptions. The IPSec_RPC_Blocker tool is also available in the IPSecTools.exe archive. Please refer to the readme.txt in the IPSec_RPC_Blocker directory for more information on this tool. Please keep in mind that after the IPSec policies are applied, remote management may also be blocked. The readme.txt has more information on how to remove the IPSec policies once a system is patched.

For more information on how to block protocols and ports using IPSec, please refer to Microsoft Knowledge Base article 813878: "How to Block Specific Network Protocols and Ports by Using IPSec" at https://support.microsoft.com/default.aspx?scid=kb;en-us;813878&sd=tech.

Disabling DCOM

On some systems, you can disable DCOM to prevent these vulnerabilities. Disabling DCOM, however, does prevent some functionality, including the ability to re-enable DCOM remotely. To re-enable DCOM, you would need physical access to the system.

When you disable DCOM, the following items will not work:

Any COM objects that can be activated remotely may not function correctly.
The local COM+ snap-in will not be able to connect to remote servers to enumerate their COM+ catalog.
Certificate auto-enrollment may not function correctly.
Windows Management Instrumentation (WMI) queries against remote servers may not function correctly.

If you still want to disable DCOM, it can be done using either the registry editor or the dcomcnfg.exe tool.

Editing the registry

Start Registry Editor.
Locate the following path:

HKEY_LOCAL_MACHINE\Software\Microsoft\OLE
Change the EnableDCOM string value to N.
Restart the operating system for the changes to take effect.

You can also use this command:

reg add \\<hostname>\HKLM\Software\Microsoft\OLE
/v EnableDCOM /t REG_SZ /d N /f

Substitute the computer name where you want to disable DCOM for <hostname>. If you want to disable DCOM on the local system, use "localhost" without the double-quotes.

Use DCOMCNFG.EXE

Run Dcomcnfg.exe.
If you are running Windows XP or Windows Server 2003, perform these additional steps:
1. Click the Component Services node under Console Root.
2. Open the Computers folder.
3. For the local computer, right-click My Computer, and then click Properties.
4. For a remote computer, right-click Computers folder, point to New, and then click Computer.
5. Type the computer name.
6. Right-click the computer name, and then click Properties.
Click the Default Properties tab.
Click to select (or click to clear) the Enable Distributed COM on this Computer check box.
If you want to set more properties for the computer, click Apply to enable (or disable) DCOM. Otherwise, click OK to apply the changes and quit Dcomcnfg.exe.
Restart the operating system for the changes to take effect.

Please note that on Windows 2000, you must run at least Windows 2000 Service Pack 3 to disable DCOM. For more information on how to disable DCOM, please see Microsoft Knowledge Base article 825750 at https://support.microsoft.com/default.aspx?scid=kb;en-us;825750&sd=tech.

Protecting Systems That Require RPC Over HTTP But Not DCOM

In some environments, DCOM is required, such as when publishing an Exchange 2003 server to clients outside the firewall using RPC over HTTP. It is still possible to protect such a system against exploits via DCOM by blocking access to TCP port 593. For more information on how to do this, follow the steps outlined in Microsoft Knowledge Base article 836382 at https://support.microsoft.com/default.aspx?scid=kb;en-us;826382&sd=tech.

How to Disinfect Infected Systems

In all cases of a worm or any other attack, it is always preferable to rebuild the system from a known good backup. In the case of the certain worms, however, such as the MSBlast worm and its variants, the worm itself does not add any additional backdoors to the system and can thus be removed. However, if the system has been infected with MSBlast, it could also have been attacked through the same vulnerability with tools that have compromised the system in such a way that it cannot be recovered. However, if you are certain that such a compromise has not occurred, you can use removal tools published by several anti-virus vendors to remove the worm:

If you have any doubts as to whether any other compromise has occurred, the system should to be rebuilt from known good media.

Patching A System During An Ongoing Worm Attack

In periods when a fast-moving worm, such as the MSBlast worm, is lose; it is not uncommon for a system to be attacked before it can be patched. Such an attack may not actually compromise the system, but could render it unstable or crash it entirely. For example, the MSBlast worm could attack two types of systems successfully – Windows 2000 and Windows XP. When the worm started infecting systems, it would chose one of the two attacks at random. While the Windows 2000 attack, for example, could successfully infect a Windows 2000 system, it would crash all other vulnerable systems if used against them. At the height of the worms spread this crash could occur so fast that it was impossible to get the system patched before it crashed. Another case where this might happen is if a virus scanner is installed on the system. The virus scanner will stop the worm from actually infecting the system. However, the actual attack itself will cause the RPC Sub System to crash, causing the system to reboot, in spite of the virus scanner stopping the infection. A virus scanner cannot stop attacks; it can only stop infections. This makes it very difficult to patch a system before it gets attacked.

There are three ways to patch such a system. All of them involve protecting the system temporarily until it can be patched. Follow these steps

Disconnect the network cable. If you are using a wireless network either remove the network interface card or disable the wireless network. You can do this from the network control panel.
Reboot the system
Log on as an administrator. Note that if the system is a member of a workgroup or if the cached credentials count has been modified from the default of 10, you need local credentials on the system to log on.
Follow one of the four methods outlined below
1. Windows 2000, Windows XP, and Windows Server 2003 systems
  
  On Windows 2000 and higher, you may use a temporary IPSec policy to block an exploit while you are downloading the patch. The policies in the IPSec tools download can be used for this purpose. Please see the section on Using IPSec to Block Attacks for more information. Once the IPSec policy is applied, you may reconnect the network cable so that you can download and install the patch. No reboot is necessary before doing so.
2. Windows XP and Windows Server 2003 systems
  
  Windows XP and Windows Server 2003 comes with ICF which would block all traffic that can exploit these vulnerabilities in its default configuration. To use this approach, follow the instructions in the section on Host-Based Firewalls for more information. Once the firewall is turned on, you may reconnect the network cable so that you can download and install the patch. No reboot is necessary before doing so.
3. All affected systems
  
  Windows NT 4.0 does not include either IPSec or a firewall. Therefore, on Windows NT 4.0 systems you need to download the patch on a protected system, save it on removable media, and then use that removable media to install the patch on the vulnerable host. This method can of course be used on any affected system, but is required on Windows NT 4.0.
4. All affected system
  
  Disable DCOM as per the instructions in the Disabling DCOM section. Note that if you disable DCOM, you must reboot the system before the changes take effect. After you have installed the patch, you would need to re-enable DCOM locally on the system before you can use DCOM services again.

These instructions should only be followed on a system that can guarantee has not been compromised by an attacker through one of these vulnerabilities. If a system has been compromised then patching will not recover the system. In that case, the only recourse is to reformat the hard drive on the system and recover from a known good backup.

For Technical Assistance

Contact your antivirus vendor for assistance with identifying or removing virus or worm infections. If you need more help with virus-related issues, please contact Microsoft’s Product Support Services (PSS). We are currently experiencing a high call volume and apologize for any delay in responding.

For Microsoft PSS within the United States and Canada, call toll-free (866) PCSafety (727-2338).
For worldwide support, contact your local Microsoft office.

If you have questions about whether you are vulnerable, or about worms and viruses, please contact Microsoft’s support services (1-866-PCSafety) or your local Microsoft office. Security-related support issues are always free of charge.