ANI 0day vs. intrusion detection providers

Most people do not know how intrusion-detection systems work. The recent Microsoft 0day animated-cursor/ANI vulnerability is a good way to learn what's really going on. Most intrusion-detections systems had 0day detection for this vulnerability, and were therefore detecting the 'unknown' attacks before everyone else knew about them.

The reason a product could detect this is because signatures are usually based on vulnerabilities rather than exploits. This new bug is essentially the same as an earlier bug in 2005, so the old sigs could detect the new variant of 2007.

Understanding vulnerability-based signatures starts with understanding the vulnerability itself. Animated-cursors are generic Microsoft multimedia files like .avi and .wav. The animation information is contained in a subsection starting with the string "anih". That string is followed by a structure
that looks like:

struct tagANIHeader {
DWORD cbSizeOf; // Num bytes in AniHeader (36 bytes)
DWORD cFrames; // Number of unique Icons in this cursor
DWORD cSteps; // Number of Blits before the animation cycles
DWORD cx, cy; // reserved, must be zero.
DWORD cBitCount, cPlanes; // reserved, must be zero.
DWORD JifRate; // Default Jiffies (1/60th of a second) if rate chunk not present.
DWORD flags; // Animation Flag (see AF_ constants)
} ANIHeader;

This structure contains nine 4-byte values, so the length field should always be exactly 36 bytes. The vulnerability is an unchecked stack overflow from code that looks like:
ANIHEADER anihdr;
memcpy(&anihdr, p+4, *(DWORD*)p);

Signatures for this vuln work by looking for the "anih" section then testing the length field to see it is longer than 36 bytes. The follow is an edited signature from the Snort intrusion-detection system that was written for the 2005 bug that also detects the 2007 variant:

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (\
msg:"WEB-CLIENT Microsoft ANI file parsing overflow";\
content:"RIFF"; nocase; \
content:"anih"; nocase; \
byte_test:4,>,36,0,relative,little;\
);

This signature first triggers on the pattern "RIFF" for the Microsoft generic multi-media file format. It then triggers on the pattern "anih" for the vulnerable subsection. It then extracts a 4-byte length field, relative 0 bytes from the end of the "anih" pattern, and triggers when that length is greater than 36.

This is how things are done in the intrusion-detection industry, yet when you take a class on intrusion-detection, they claim it ISN'T done this way. Instead of vuln-analysis and vuln-sigs, they teach you that intrusion-detection is done by analyzing the exploit, looking for patterns unique to that exploit.

Since most intrusion-detection products had 0day detection for this bug it stands to reason that intrusion-detection SERVICE PROVIDERS should also have had detection. YOU SHOULD ASK THEM. I'm sure if you read the marketing literature of product and service providers, everything is wonderful, but if you force them to prove to you that they were detecting this problem, things might not be so rosy. The service provider might have been using a poor intrusion-detection system. The signature might have had too many false-positives so was disabled. Or somebody was stupid and just didn't turn on the signature. I would love to see every managed intrusion-detection provider publish a graph of the detection of this bug over the last 6-months. (Indeed, I'm a bit annoyed right now since I no longer work for Internet Security Systems, and I can't just ask the service-provider folks to execute a database query for me).

The reason I suggest talking to service providers is that while most intrusion-detections systems based their signatures on vulnerabilities, there is still a big difference in the quality of the signatures. For example, the above Snort signature is prone to false positives. Any file containing both "RIFF" and "anih" will likely trigger the bug. While this is rare for any particular sensor, this is a high enough rate of false-positives that a large service-provider might turn off the signature.

The above signature only works on a small number of ports assigned to HTTP. In reality, hostile servers are delivering this attack on virtually any port. Another problem is that Snort is typically configured to only analyze the first few hundred bytes of an HTTP response, which means it will miss the attack unless it's the first filed deliver in a response.

The above signature example only covers HTTP, but it can come across other transports, such as instant messengers or e-mail. As far as I can tell, no Snort signatures have been written for these other transports. Indeed, it was announced that e-mail spam was a major vector for this attack.

I point these flaws out because people treat intrusion-detection like magic. They don't understand the signatures they download and put in their intrusion-detection systems, but instead treat them as magical incantations. After every major event, I see signatures posted to various websites, but they are usually incomplete. That's why you pay more for commercial products: they invest more in detection. For example, Proventia (the product I worked on) solves the above problems because it has a full protocol-stack; indeed, many customers are using it right now to block high rates of ANI exploit spam. However, since most people treat signatures as magic, there is little discussion about what's really going on with the signature. It's not hard creating better signatures, it's just that since so few classes teach how signatures are actually developed, and so few users actually read the signatures, that there is no pressure to create better ones.