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)
- 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
At the DCERPC layer, there even more differences. There are versions that differ greatly on the packet level:
- v4 (request based)
- v5 (session based)
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.