Regarding this interesting discussion I would like to add some thoughts:
I would like to discuss IPSes primarily here. Yes, they are pretty
messy in handling the application layer decoding. As told by David,
application layer attacks like RPC Fragmentation are very effective to
bypass them. Apart from that there are some other miscellanious
(boring) stuff like data encoding, language locales encoding, mixed
encoding and some file system syntax problems (yes, some unfixed
problems do exist in Apache running over Windows versions). However
these problems are not practically exploitable in common cases.
BUT Leaving apart all these problems apart, I feel the major problem
is how the device is handling the protocol decoding logic. Any clever
guy with some experience in IPSes will know what the major problem
with them is. It's the difference in protocol decoding logic of
protection device and that of application which it is protecting or
*maybe* the "vantage point problem" . But the reason for occurrence of
"vantage point problem" is not precisely what Thomas said, from my
personal experiences. False positives and false negatives can arise
due to following reasons...
1. Most protocol decoders use lexing and parsing. A bug in the lexing
and parsing scheme (something which leads to a un-accountable state of
parser) can lead to failure of protocol decoder. This can lead to the
protection device bypass depending on how it handles the connection on
failure.
(Question: How do we know where lexing and parsing is implemented?
Ans: Well, ummm...in case of open source apps like Apache see source.
IPS decoders are copy cats)
2. Most protocol decoders follow RFC specifications. However as all of
you know, the applications are the worst implementations of RFC. Any
of these issues can lead to succesful bypassing of protection device
a) Delimiters used in application and those specified in RFC are
different (for text based protocols primarily). It leads to bad
decoding of various entities of protocol.
b) State variables are not commonly stored in protocol decoders of
devices, which can lead to false positives.
c) Differnet entities of protocols have max limits in different
applications like Apache, IIS (RFC does not specify limits). Many
applications handle these limits with some escape logic like "eatline
till newline" for session continuation. This is major point where you
can strike.
d) Device protocol decoding logic is pretty simple and weak, so it's
easy to break too.
Summarizing it all, do a diff of decoding logic of application (can
take Open Source servers as test beds) which the IPS is protecting and
the prescribed RFC standard and you will know how to bypass the box.
:)))
On Fri, 3 Dec 2004 16:17:06 -0500, Thomas Ptacek <tqbf@arbor.net> wrote:
Research subsequent to the papers that Paxson, Newsham, and I wrote
established the term "vantage point problem" to describe the failure
mode where a monitoring system gets tripped up by the differences
between its own protocol logic and the logic of a real implementation
of that protocol on an end system.
We've seen vantage point problems in a variety of places --- probably
most notably in HTTP and in SMB.
My considered opinion is that vantage point problems are the "buffer
overflow" vulnerability of the monitoring/integrity field.
I think most people would concede at this point that the best solution
to buffer overflow attacks is to preclude them from existing: automatic
bounds checking, least-privilege OS enforcement, and stack/heap
integrity guards. Chasing the "next" buffer overflow and following the
discover/wait/publish/patch cycle is probably not an effective
strategy.
Similarly, the real solution for the vantage point problem is to
preclude consistency problems --- by proxying, scrubbing, or moving
functionality closer to the end-systems.
So I guess that I'm saying that you're right, David, and that there are
lots of places to look besides TCP headers for these problems.
On Dec 1, 2004, at 4:49 PM, Maynor, David (ISS Atlanta) wrote:
Aside from looking at this the best way to learn to evade IDS/IPS is an
understanding of the protocols that they are protecting. This doesn't
mean just TCP/UDP; this also means things like MSRPC, HTTP, SSL and
such.
---
Thomas H. Ptacek // Product Manager, Arbor Networks
(734) 327-0000
--------------------------------------------------------------------------
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.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
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.
--------------------------------------------------------------------------
