Microsoft originally released this bulletin and patch on July 16, 2003 to correct a security vulnerability in a Windows Distributed Component Object Model (DCOM) Remote Procedure Call (RPC) interface. The patch was and still is effective in eliminating the security vulnerability.

However, the “mitigating factors” and “workarounds” discussions in the original security bulletin did not clearly identify all of the ports by which the vulnerability could potentially be exploited. We have updated this bulletin to more clearly enumerate the ports over which RPC services can be invoked, and to ensure that customers who have chosen to implement a workaround before installing the patch have the information that they need to protect their systems. Customers who have already installed the patch are protected from attempts to exploit this vulnerability, and need take no further action.

Remote Procedure Call (RPC) is a protocol used by the Windows operating system. RPC provides an inter-process communication mechanism that allows a program running on one computer to seamlessly execute code on a remote system. The protocol itself is derived from the Open Software Foundation (OSF) RPC protocol, but with the addition of some Microsoft specific extensions.

There is a vulnerability in the part of RPC that deals with message exchange over TCP/IP. The failure results because of incorrect handling of malformed messages. This particular vulnerability affects a interface with RPC, which listens on RPC enabled ports. This interface handles DCOM object activation requests that are sent by client machines to the server. An attacker who successfully exploited this vulnerability would be able to run code with Local System privileges on an affected system. The attacker would be able to take any action on the system, including installing programs, viewing changing or deleting data, or creating new accounts with full privileges.

To exploit this vulnerability, an attacker would need to send a specially formed request to the remote computer on specific RPC ports.

Mitigating factors:

To exploit this vulnerability, the attacker would require the ability to send a specially crafted request to port 135, 139, or 445 or any other specifically configured RPC port on the remote machine. For intranet environments, these ports would normally be accessible, but for Internet connected machines, these would normally be blocked by a firewall. In the case where these ports are not blocked, or in an intranet configuration, the attacker would not require any additional privileges.
 Best practices recommend blocking all TCP/IP ports that are not actually being used, and most firewalls including the Windows Internet Connection Firewall (ICF) block those ports by default. For this reason, most machines attached to the Internet should have RPC over TCP or UDP blocked. RPC over UDP or TCP is not intended to be used in hostile environments such as the Internet. More robust protocols such as RPC over HTTP are provided for hostile environments. To learn more about securing RPC for client and server please refer to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/writing_a_secure_rpc_client_or_server.asp.


To learn more about ports used by RPC, please refer to: http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/tcpip/part4/tcpappc.asp.

Severity Rating
Windows NT 4.0    Critical
Windows NT 4.0 Terminal Server Edition    Critical
Windows 2000    Critical
Windows XP    Critical
Windows Server 2003    Critical

The above assessment is based on the types of systems affected by the vulnerability, their typical deployment patterns, and the effect that exploiting the vulnerability would have on them.

Vulnerability Identifier CAN-2003-0352

Tested Versions

Microsoft tested Windows Me, Windows NT 4.0, Windows NT 4.0 Terminal Services Edition, Windows 2000, Windows XP, and Windows Server 2003 to assess whether they are affected by this vulnerability. Previous versions are no longer supported, and may or may not be affected by this vulnerability.

Microsoft thanks The Last Stage of Delirium Research Group for reporting this issue to us and working with us to protect customers.

Description of Events

For a detailed analysis of this exploit, see: http://www.xfocus.org/documents/200307/2.html.

I've never seen an exploit develop so quickly in my life. The hacker underground was rocked for 4 whole days. It was a gruesome sight - machines we're being "Dropped" (hacked) at an insane rate. It was obvious that a large majority of computers were still not patched.

I watched sadly, as the Internet was being violated, innocent victims becoming the unsuspecting targets of over hormone-ized teenage kids. One by one they fell, while the hackers slaved relentlessly to gain control over more and more machines. At some stage, I even saw an IRC channel that had the topic "RPC – DCOM – Leave some for the worm!". There was nothing I could do, except to warn everyone I knew.

The first exploit released by Xfocus was rather anticlimactic, as it was found to be a DOS attack, and not the promised SYSTEM shell. However, redemption was soon to come as Metasploit published a fixed fully working exploit, a few days later.