focus-ids October 2007 archive
Main Archive Page > Month Archives  > focus-ids archives
focus-ids: RE: IDS detection approaches

RE: IDS detection approaches

From: Nelson Brito <nbrito_at_nospam>
Date: Tue Oct 09 2007 - 20:16:39 GMT
To: "'Sec urity'" <>

> There are few commercial IPS products that stand up to informed
> scrutiny as well as Snort. Too bad many commercial black box vendors
> are allowed to claim something other than reality. What leads you to
> believe that other vendors are not simple signature engines or are
> some how superior?

I didn't say that any other IDS/IPS do a superior or a super detection, I just said that PATTERN MATCHING is so "cat X | grep X", even if you are naming it as regex, just to give a new name. BTW, regex do a better PATTERN MATCHING, anyway...

I didn't claim the death of pattern, I'm just saying that there are better ways to understand and detect an attack to vulnerability, using mixed approaches and new technologies, and I do prefer to detect an attack to vulnerabilities by using vulnerabilities signature algorithms instead of PATTERN MATCHING. As far as I know, there are too many ways to evade any IDS/IPS, but how many ways work in just one IDS/IPS defines which one is the better approach, and I can tell you that any IDS/IPS that has all their computational resources to do PATTERN MATCHING is more susceptible to well known and unknown attacks addressing PATTERN MATCHING weakness.

Lets check the the following signature:
alert udp $EXTERNAL_NET any -> $HOME_NET 1434 (\ msg:"MS-SQL version overflow attempt";\ flowbits:isnotset,ms_sql_seen_dns; dsize:>100; content:"|04|"; depth:1;\ reference:bugtraq,5310;\ reference:cve,2002-0649;\ reference:nessus,10674;\ classtype:misc-activity; sid:2050; rev:8;\ )

Does it protect you agains SLAMMER? Yes, it does... But it opens a door to do a False Positive attack.

There are four main variables for this vulnerability work: - Protocol UDP - Port 1434 - SQL Request 0x04 (first byte in the payload) - Buffer size > 96, with no NULL byte and being the 96th byte the return address to be overwrite.

If you miss any of them you are not able to exploit the SQL Server.

FACT!!! We can see that the previous signature (PATTERN MATCHING) looks for: protocol UDP, port 1434, first byte in payload equals to 0x04 and the size of 100 (buffer of 96 bytes + and the new return addres of 4 bytes)... But there is no check to ignore payload with 96 NULL bytes.

FACT!!! What if you send 1,000,000 packets with the following payload to port 1434/UDP? "\x04\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"

I can tell you: 1,000,000 events... Sorry, false events, as known as false positives. How bad could it be to your PATTERN MATCHING? I can tell you: - HD exhaust - 100% of CPU - Memory exhaust - etc etc etc

FACT!!! Some of "smart" IDS/IPS will shutdown the signature to prevent itself of rebooting of any other damage, just like that.

There are some signatures detecting the return address "0x42b0c9dc", but there are three different return addresses in the same DLL.

FACT!!! Some of IDS/IPS uses "complex" ways to detect the shellcode, just like SNORT, but... Guess what? There are portions of the shellcode, even using "polymorphic shellcoding", that are still static. And due to that it is possible to detect the encoder instead of the rest of encrypted shellcode. But, guess what, again? You can do your own encoder to defeat this detection.

> This is an easy target that recently got updated in the _signature_
> packs of one vendor that claims to be other than a fast regex engine.

Regex is just a complex way to write signatures to prevent character insertion in the pattern, but it still is a PATTERN MATCHING. Do you remember the (in)famous "CWD ~ROOT" and "CWD\t~ROOT"?

> > I think the best approach is when vendors get the knowledge of how the
> vulnerabilties work, istead of how the exploits exploit the vulnerability.
> This is so reactive that any new exploit / worm variant will require a new
> signature.
> >
> > Keep in mind that when you know how the vulnerability can be exploited
> is better than know how so many exploits works, but it is not that easy! A
> signature database based on pattern is easier but gives you worng sense of
> protection, and this worse than no protection.
> >
> > That said, IMHO, anomaly detection + signature database based on
> vulnerabilties + behavior detection + any other approach other than
> >
> > My 2 cents.
> Do not underestimate the value of signatures in protocol modeling.
> Especially when it is backed by a rules language that allows for full
> protocol state tracking and analysis.

Protocol modeling must understand and decode the protocol, and it just works if you have good and sanitized signatures, otherwise you still have and will have problems...

> All protocols have patterns, these patterns are often identifiable by
> signatures. This is perhaps why people often confuse the snort rules
> language with a purely signature based engine. That perception could
> not be farther from the truth. In a simple form there are a few
> components that come together to facilitate far more sophisticated
> analysis.
> 1) Preprocessors - These are best described as protocol normalizers,
> generally employed when protocols have multiple representations that
> need to be accounted for. They can also be used for crypto,
> behavioral, and anomaly based detection in a faster way than rules can
> support alone.
> 2) Signatures - These are your standard pattern matching methods
> generally employed
> 3) Rules - These allow you to do the really cool things with traffic
> analysis without writing code.
> EG:
> - Find the field marker for buffer size denoted by the pattern |03 04 06
> FE|
> - At the end of the marker, take four bytes and interpret them as an int
> - Jump that many bytes forward in the payload
> - From that position find the op code for open file
> - At the open file op code location test the value of file size, if
> it is greater than 128 there is a vulnerable condition.

Ask your preferred pen-tester how easy is to compromise this detection, even using either false negative or false positives.

Best regards.

My US$ 1.

Nelson Brito (
Senior IPS Engineer & Pen-tester

Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from CORE IMPACT. Go to to learn more.