Re: [Emerging-Sigs] TCP Portals: The Handshake's a Lie!

[Jason Brvenik <jasonb () sourcefire com>]

On Tue, Nov 24, 2009 at 11:34 AM, Frank Knobbe <frank () knobbe us> wrote:
> On Tue, 2009-11-24 at 00:30 -0500, Jason Brvenik wrote:
> > While fine and likely supported behavior in a few clients, it is not
> > normal. The only servers that would be responding with a SYN would be
> > malicious ones.
>
> Or systems that run 30 year old TCP stacks :)

/me thinks if that were the case they would be having problems today.

> > I suspect this is why scanning with a SYN from common services ports
> > is sometimes successful. A more interesting CS project would be to
> > determine if in that case you can cause a connection to build to valid
> > internal services.
>
> Nope, that's a different issue. Scanning with source port set to 20 can
> bypass lame firewalls. Not just stateless firewall, but I've even sailed
> past a Checkpoint that had the FTP proxy thingy misconfigured.
>
> Keep in mind that the SYN from the server to the client uses the IP:port
> pairs on both sides of the packet. The only difference is that the ACK
> flag is not set and it doesn't include the initiators sequence number.
> This is not a "rogue" SYN that has a different port or even IP (as being
> sent from a different device).
>
> Now, if you intercept the SYN from the client to the server and know the
> IP:port quartet, and you spoof a packet back from a different host with
> the expected IP:port values, you would interfere with the TCP session
> setup between client and server, nothing more. You won't be able to
> establish a new session from a different host to the client, since the
> clients internal parameters (socket/TCB) are different. There is no
> in-progress session setup from the client to that rogue box, so why
> would the client care? It would just drop the packet, most likely
> respond with a SYN-RST.

my though here is not what should be happening but if a poorly
designed / implemented system in an effort to accommodate this valid
behavior might well let ip:80 -> ip:7627 establish a session much like
a poorly implemented system that doesn't recognize
SYN/[PSH,URG,ETC...] can establish state with some stacks.


> > That was my quick read as well but I'm not an authoritative source.
> > Regardless, it is anomalous and unexpected behavior and blocking would
> > be trivial and non-destructive and likely from a malicious server.
>
> Blocking yes, and firewalls may do that already. See, the client
> (initiator) sends a SYN, a firewall in the middle sees that and begins
> to track state of that session. The server (receiver) responds with a
> SYN-ACK, which the firewalls sees and enters that session into its state
> table.
>
> Now, the server might send a SYN-RST if the port is closed. The
> firewalls seems that and stop tracking this session.
>
> If the server sends a SYN, the firewall can either move the session into
> an established state (waiting for ACK for example) and enter it in a
> state table, or stop tracking the session.
>
> Either way, no harm done. It either behaves as expected by marking the
> session as established, or drop it. It reacts safely.

thanks for the education in flow handling, it was not clear to me :)

> An IDS however doesn't have the luxury of failing safe. It either tracks
> the session (which it sounds we believe Snort does), or it doesn't. But
> when it doesn't, it means that there is an established session that will
> fly past the IDS. It fails in an undesireable fashion.

And an IPS has an entirely different set of actions it can take. My
point here is that if your systems are designed that an attack against
the IDS using this method is possible ( knowing all of the other
hurdles ) you have bigger problems.

> Anyway, this whole thing is more of a curiosity of a nearly 30 year old
> TCP stack behavior then a threat to systems or firewalls. But it may
> cause session tracking devices to ignore a session.
>
> Gotta run to meetings.
>
> Cheers,
> Frank

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users