[Snort-devel] Evading Snort via splitting ACKs
cpw at ...86...
Mon Sep 23 11:47:01 EDT 2002
On Mon, Sep 23, 2002 at 11:50:53AM -0400, David J. Bianco wrote:
> I was reading through some snort rules the other day, just doing
> some general maintenance things, when I got a strange idea. Most of the
> rules that come with snort use the "flags: A+" construct, or the
> "established" for snort 1.9. I know that this is intended to ensure
> that the rules only fire off for connections which have successfully
> completed the three-way handshake, but I think it also leaves open a
> hole which can be used to evade the IDS. Using some trickery, you can
I do believe that you can formulate a packet that looks like tcp with
the exception of an ack bit, and has as much data you can cram in to
it or multiple fragments, up to 65,635 octets. Also, a rule that
expects the ack bit will no be exercised under those conditions.
However, a tcp implimentation that doesn't drop the segment and silently
return to await a properly formed tcp packet is a broken implimentation.
Or, I don't understand RFC 793 all that well.
> slip past any rule which relies on "flags: A+" fairly easily.
> In most implementations of TCP, the ACK flag piggybacks on top of data
> packets. Thus, if I were to send a "HEAD / HTTP/1.0\n\n" to my favorite
> web server, not only would those bytes appear in the packet's payload,
> but the ACK for the last part of the connection establishment
> handshake would appear also. The TCP specification, though, allows
> ACKs to be entirely separate. In other words, I can ACK data without
> sending any payload, and I can send a payload without sending an ACK
> in the same packet. And if I don't send a payload without an ACK
> attached to it, the server will still receive the data but snort won't
> match it to any rule that uses "flags: A+".
> I've developed a short piece of code which demonstrates this concept,
> and indeed, the snort rule fails to fire. I'm sure I'm not the first
> person to notice this, so I was wondering what other people are doing
> to help mitigate their exposure to this sort of evasion.
> David J. Bianco, GSEC <bianco at ...1589...>
> Thomas Jefferson National Accelerator Facility
> GPG Fingerprint: 516A B80D AAB3 1617 A340 227A 723B BFBE B395 33BA
> The views expressed herein are solely those of the author and
> not those of SURA/Jefferson Lab or the US DOE.
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
Phil Wood, cpw at ...86...
More information about the Snort-devel