IDS mailing list archives

RE: Foolin an IDS ?


From: "Maynor, David (ISS Atlanta)" <dmaynor () iss net>
Date: Sun, 5 Dec 2004 10:13:45 -0500

Most IDS/IPS Vendors today account for the papers mentioned.  

Yup. I feel really sorry for any vendor that is currently evaded by ip
fragmentation. But the papers have a historical value of putting the
reader in the mindset required to nitpick how IPS's are built. 

Test methodologies for IDS/IPS technologies has mutated a bit.  

I am sure glad. The "pay no attention to the man behind the curtain" bit
has gotten old.

Some IDS/IPS vendors utilize various commercial and non-commercial
tools 
to test their products, The issue at hand is how does one separate out

true IPS evasion techniques to validate IPS based attacks only.

You would have to start with the question what is a true IPS evasion
technique? I tend to think of it as any technique used to take an
exploit that is normally stoppable by the IPS and get it by with no
detection. 

Going on this definition I would build an attack tree based on what
works and what doesn't. Two stage testing seems to be in order. Find a
public that the IPS should stop without question. A great example would
be MS03-026. I really feel if you can't stop MS03-026 you should not
call yourself an IPS. Run the vanilla public proof-of-concept and record
on a clipboard if it is detected or not. A labcoat may also be in order.


Now you have a baseline for the IPS performance. At this point IPS
evasions techniques can be applied. Based on the results of these you
can tell where the vendor has problems. For instance if RPC
fragmentation bypasses it's a pretty safe bet that and protocol that has
the ability to fragment or chunk you can most likely sneak attacks by.
This can build a pretty nice tree for testing true IPS evasions. 

The baseline exploit should be constantly changed or vendors we will the
same type of enhancements in this space as tester found in the video
card space. Results can be cooked to do one thing very well but are not
indicative of real world results.

These are false-negatives though, or getting an attack by that the
device should trigger on. False positives are useful for testing how
well things are actually detected. Things like embedding the offending
GUID from MS03-026 in a word doc and seeing if the corresponding alert
is raised gives enormous insight into the detection ability of the
device. 





--------------------------------------------------------------------------
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 http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
to learn more.
--------------------------------------------------------------------------


Current thread: