With the release of Sourcefire's coverage for MS08-067, I've heard the same question repeatedly. "Why 114 rules? They were able to do it with just one." Since I wrote these rules, I'm the best to explain my solution.

I will not be going over the explicit nature of the vulnerability, but I will cover the protocol details that lead up to the vulnerability that make up my solution. The end goal of all of the rules is to detect attack traffic, while not alerting on benign traffic.

Detecting the underlying attack isn't that hard, in fact its pretty easy. While I could write one rule that looks for the basic information used in the attack, that basic information shows up all over the place. Printing to file transfers all include traffic that would set off the basic attack.

The hard part is making sure the detection only detects attacks, not benign traffic. My solution attempts to handle all of the potential methods for getting to the field that can be abused to exploit this vulnerability, and only do the detection of the attack on that field. The rules must handle all of the differences and neuances of the underlying protocols to limit detection to just the field in question. To that end, here are the primary neuancies that show up in nearly every DCERPC vulnerability.

First, the vulnerability is in a DCERPC service. DCERPC is accessable by a number of different methods:

  • netbios-ssn (139)
  • netbios-ds (445)
  • netbios-dgm (138)
  • NCACN-IP-TCP, direct DCERPC via TCP. (135, 593, or 1024 and above)DCERPC over netbios has a number of protocol variations that need to be accounted for in the rules. Netbios has multiple common ways to get to DCERPC:
  • WriteAndX
  • TransMultiple SMB commands allow additional commands to be done after the original command in a single request. These commands have the nomeclaiture of "AndX". Examples of this would be:
  • WriteAndX with DCERPC
  • Trans with DCERPC
  • OpenAndX followed by Trans with DCERPC
  • OpenAndX followed by WriteAndX with DCERPC
  • OpenAndX followed by ReadAndX followed by WriteAndX with DCERPC
  • etcSMB allows for normal and unicode string types, both of which are different at the packet level.

At the DCERPC layer, there even more differences. There are versions that differ greatly on the packet level:

  • v4 (request based)
  • v5 (session based)Integers can be represented on the wire as big endian or as little endian. In addition, there is a 16 byte object identifier that may or may not be set in a given request.

Handling all of these permutations combines to a set of 114 rules. If you think I wrote all of these permutations by hand, you are nuts. I am firmly in the code-generation camp. Some time ago, I wrote a code generator that handles all of the permutations for me, allowing me to focus on the specifics of the attack, not the specifics of the protocol.