Using A Microsoft DCOM Vulnerability Exploit -

A step by step guide to testing your system and ways to mitigate the threat

By: Darrin Mourer, CISSP

An extremely high risk vulnerability to Microsoft operating systems was posted to Bugtraq on July 17^th by the Last Stage of Delirium research group. The initial posting reserved details on the vulnerability. Right around the same time Microsoft confirmed the vulnerability and released a security bulletin numbered MS03-026 outlining the problem with links to appropriate patches.

It didn’t take long for details of the vulnerability to leak out and a little over a week later exploit code was published, again to Bugtraq. The exploit code was further refined into what I will be demonstrating. The exploit code is now available in source code format, Linux script, and Windows executable. It is the Windows executable that we will be testing.

I have included a full write up of the vulnerability toward the end of this article, but here are some up front basics. The problem lay in an unchecked buffer in the Windows DCOM component of the Remote Procedure Call service bound to port 135. This service spawns a process named svchost.exe, which is the running process that is attacked. Depending on your Windows version and service pack level, the exploit must be changed slightly. Luckily, the latest exploit code we are looking at has a menu built right in to choose the proper version.

There are three files (two critical) that are needed to perform the exploit:

- dcom32.exe (exploit code)

- nc.exe (netcat, a utility to connect to the exploited machine)

- Optionally: a batch file which automates the process - rcpx.bat

Let’s view the exploit in action…

You first need to download the files to your hard drive. Then open up a command prompt. Type in dcom32.exe and press enter to get a print out of the correct syntax.

Figure 1.

You notice the menu which allows you to choose which version of the exploit you would like to run. From the example, to attack at Windows 2000 SP 4 machine you would type:

Dcom32 4 <victim IP>

If it is successful the exploit will give you instructions to run netcat to connect to the victim machine. The syntax of this operation is nc –vvv <victim IP> 4444

-vvv is optional and is used to display verbose output. 4444 is the default port the exploit uses. More about the port later.

If you are successful, a command prompt will be available on the victim machine. This whole process will look as follows.

Figure 2.

You can optionally run the batch file which automates this process. So instead of typing in:

Dcom32 4 192.168.0.4

Nc –vvv 192.168.0.4 4444

You would type in rcpx <option number> <victim IP> and press enter. Same result as before.

It is now trivial from this point on to connect back out and download your favorite tools de jour. A couple of notes about the exploit I have noticed in my testing:

- All of the versions of the tool seem to work fairly flawless except for Windows 2000 SP 3, two machines I tested with on this version would not work

- When you run the exploit you will kill the svchost.exe host process, even if you don’t get a shell. This means be sure of the host version before you run the tool. Otherwise you are waiting for a reboot before you can try again.

- The netcat listener on 4444 seems to only accept the first connection attempt. Subsequent connections after disconnecting would not be accepted. This means if you exploit this as part of a penetration test you should create your own stable netcat daemon on the server before disconnecting.

Remediation and Protection

Now yes of course the first thing you need to do is go to the Microsoft link from their security bulletin and install their patch. This is not always an option for security administrators in large distributed networks. Here are some other options.

Network IDS

This being a remotely exploitable vulnerability, you must be vigilant in detecting these attempts on your network. I will use Snort as my example IDS. This first step is to apply the following signature(s):

alert tcp $EXTERNAL_NET any -> $HOME_NET 135 (msg:"DCE RPC

Interface Buffer Overflow Exploit"; content:"|00 5C 00 5C|";

content:!"|5C|"; within:32; flow:to_server,established;

alert tcp $EXTERNAL_NET any -> $HOME_NET 135 (msg:"NETBIOS DCERPC invalid bind attempt";

flow:to_server,established; content:"|05|"; distance:0; within:1; content:"|0b|";

distance:1; within:1; byte_test:1,&,1,0,relative; content:"|00|"; distance:21; within:1;

classtype:attempted-dos; sid:2190; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET 445 (msg:"NETBIOS SMB DCERPC invalid bind

attempt"; flow:to_server,established; content:"|FF|SMB|25|"; nocase; offset:4; depth:5;

content:"|26 00|"; distance:56; within:2; content:"|5c 00|P|00|I|00|P|00|E|00 5c 00|";

nocase; distance:5; within:12; content:"|05|"; distance:2; within:1; content:"|0b|";

distance:1; within:1; byte_test:1,&,1,0,relative; content:"|00|"; distance:21; within:1;

classtype:attempted-dos; sid:2191; rev:1;)

There have also been a variety of other signatures floating around that catch the shellcode aspect of the attack. Many of these are hard coded to look at port 4444, which is the default listener port. However since there is open access to the exploit code, it is next to trivial to alter that port. Therefore I recommend if you want to catch the listener use an “any” instead of 4444 in your rule.

Host IDS

Since there really isn’t a de facto standard for Host IDS (or a widely used open source version) we will keep this high level. If your host protection affords you a firewalling component you can easily stop port 135 traffic from entering the server. If your host protection affords you process monitoring, a policy not allowing the svchost.exe process to spawn additional processes would also prevent this exploit from taking hold. You can also turn on process tracking from within windows and look for a process stop for svchost.exe. Between those detection methods a successful intrusion should definitely not go unnoticed.

Firewall

The easy answer is block port 135 and 4444 from entering your network, but there are a few more possibilities. If you are going through a proxy or application firewall, they may block the exploit by default as it doesn’t conform to RFC specifications. You may also be able to block random destination ports leaving your network. This may force the attacker to open up a listener on a well known port, one that you may have the ability to scrutinize further.

Alternate Sources

There are many sources of information on this vulnerability. Some are listed at the conclusion. Here the write up from Symantec Security Response:

Microsoft Windows DCOM RPC Interface Buffer Overrun Vulnerability

Risk
High

Date Discovered
07-16-2003

Description

A buffer overrun vulnerability has been reported in Microsoft Windows that can be exploited remotely via a DCOM RPC interface that listens on TCP/UDP port 135. The issue is due to insufficient bounds checking of client DCOM object activation requests. Exploitation of this issue could result in execution of malicious instructions with Local System privileges on an affected system.

This issue may be exposed on other ports that the RPC Endpoint Mapper listens on, such as TCP ports 139, 135, 445 and 593. This has not been confirmed. Under some configurations the Endpoint Mapper may receive traffic via port 80.

Components Affected
Microsoft Windows 2000 Advanced Server SP4
Microsoft Windows 2000 Advanced Server SP3
Microsoft Windows 2000 Advanced Server SP2
Microsoft Windows 2000 Advanced Server SP1
Microsoft Windows 2000 Advanced Server
Microsoft Windows 2000 Datacenter Server SP4
Microsoft Windows 2000 Datacenter Server SP3
Microsoft Windows 2000 Datacenter Server SP2
Microsoft Windows 2000 Datacenter Server SP1
Microsoft Windows 2000 Datacenter Server
Microsoft Windows 2000 Professional SP4
Microsoft Windows 2000 Professional SP3
Microsoft Windows 2000 Professional SP2
Microsoft Windows 2000 Professional SP1
Microsoft Windows 2000 Professional
Microsoft Windows 2000 Server SP4
Microsoft Windows 2000 Server SP3
Microsoft Windows 2000 Server SP2
Microsoft Windows 2000 Server SP1
Microsoft Windows 2000 Server
Microsoft Windows NT Enterprise Server 4.0 SP6a
Microsoft Windows NT Enterprise Server 4.0 SP6
Microsoft Windows NT Enterprise Server 4.0 SP5
Microsoft Windows NT Enterprise Server 4.0 SP4
Microsoft Windows NT Enterprise Server 4.0 SP3
Microsoft Windows NT Enterprise Server 4.0 SP2
Microsoft Windows NT Enterprise Server 4.0 SP1
Microsoft Windows NT Enterprise Server 4.0
Microsoft Windows NT Server 4.0 SP6a
Microsoft Windows NT Server 4.0 SP6
Microsoft Windows NT Server 4.0 SP5
Microsoft Windows NT Server 4.0 SP4
Microsoft Windows NT Server 4.0 SP3
Microsoft Windows NT Server 4.0 SP2
Microsoft Windows NT Server 4.0 SP1
Microsoft Windows NT Server 4.0
Microsoft Windows NT Terminal Server 4.0 SP6a
Microsoft Windows NT Terminal Server 4.0 SP6
Microsoft Windows NT Terminal Server 4.0 SP5
Microsoft Windows NT Terminal Server 4.0 SP4
Microsoft Windows NT Terminal Server 4.0 SP3
Microsoft Windows NT Terminal Server 4.0 SP2
Microsoft Windows NT Terminal Server 4.0 SP1
Microsoft Windows NT Terminal Server 4.0
Microsoft Windows NT Workstation 4.0 SP6a
Microsoft Windows NT Workstation 4.0 SP6
Microsoft Windows NT Workstation 4.0 SP5
Microsoft Windows NT Workstation 4.0 SP4
Microsoft Windows NT Workstation 4.0 SP3
Microsoft Windows NT Workstation 4.0 SP2
Microsoft Windows NT Workstation 4.0 SP1
Microsoft Windows NT Workstation 4.0
Microsoft Windows Server 2003 Datacenter Edition
Microsoft Windows Server 2003 Datacenter Edition 64-bit
Microsoft Windows Server 2003 Enterprise Edition
Microsoft Windows Server 2003 Enterprise Edition 64-bit
Microsoft Windows Server 2003 Standard Edition
Microsoft Windows Server 2003 Web Edition
Microsoft Windows XP 64-bit Edition SP1
Microsoft Windows XP 64-bit Edition
Microsoft Windows XP Home SP1
Microsoft Windows XP Home
Microsoft Windows XP Professional SP1
Microsoft Windows XP Professional

Other Risks

There have already been reports of wide spread cohesion from the virus community on development of a new worm which will incorporate this exploit to spread. Usually a successful worm is at least a month behind a exploit release at a minimum, however the race is certainly on. Mitigating factors that may lengthen the cycle is the fact that the worm will have to be selective in which version of DCOM RPC it attempts to exploit. This means that either the worm writer will guess, make it random, or cycle the attempts. The other option is to incorporate a discovery subroutine which can identify the version and pick the corresponding exploit. This latter option is the one everyone is nervously awaiting.

One Trojan has already been released that leverages this vulnerability. Backdoor.IRC.Cirebot is the name of it and it spreads via user interaction when downloading or exchanging files. See the link section for the write up.

Closing

Take the widespread distribution of the systems affected by this vulnerability, the sheer number of versions of Windows that are affected, and couple that with the ease of the exploit, and you have a major problem on your hands. I urge everyone to take this issue very seriously and run, don’t walk, to go implement countermeasures. It is only a matter of time before a distributed attack or worm take advantage of this vulnerability.

Reference Links

Microsoft Security Bulletin

http://www.microsoft.com/technet/treeview/?url=/technet/security/bulletin/MS03-026.asp

Bugtraq Posting

http://www.securityfocus.com/archive/1/329283/2003-07-14/2003-07-20/0

Exploit Code

http://www.securityfocus.com/bid/8234/exploit/

http://www.illmob.org/rpc

http://www.remainsecure.com/software/exploits/dcom_rpc.zip

(I‘m not responsible for what you do with this code)

Vulnerability Write Ups

http://securityresponse.symantec.com/avcenter/security/Content/8205.html