Re: Foolin an IDS ?

[Pukhraj Singh <pukhraj.singh () gmail com>]

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.
> --------------------------------------------------------------------------
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
https://lists.immunitysec.com/mailman/listinfo/dailydave