Yesterday, we wrote about the Microsoft IIS FTP stack overflow. (here) Since then, we've seen some folks try to come up with detection for attacks targeting this vulnerability.

Here's some things to think about when detecting this attack:

1. We saw some rules that detected the SITE command as the vulnerable condition for exploitation, this is not where the problem lies. Its in the NLST command when it parses long directory names. The SITE command in the released exploit (archived on milw0rm) is used to store shellcode into memory, so it can be egghunted later when the exploit is triggered. While looking for the SITE command will detect attempts to use this particular exploit, there are plenty of other ways to store your shellcode in memory before triggering this vulnerability, which would evade anything using the SITE method for detection.
2. One of the things that all snort rule writers should remember is that to keep performance of the engine up, you need to look for ways to "fail" your rule as quickly as possible. Before doing something like a "not content" check at some distance into the packet, use something like isdataat to determine if the packet is actually that big before doing the check. We've seen rules for this vulnerability that don't do this, even though you're talking about microseconds for one rule, if you have lots of rules that don't conform to this then the effect is cumulative. Performance can then become an issue.