Great Circle Associates Firewalls
(November 1997)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: Hijak detection
From: Jason Keimig <jkeimig @ idir . net>
Date: Wed, 5 Nov 1997 11:39:49 -0600 (CST)
To: Adam Shostack <adam @ homeport . org>
Cc: Frank Willoughby <frankw @ in . net>, firewalls @ GreatCircle . COM
In-reply-to: <199711050809 . DAA01853 @ homeport . org>


> The point that (doy?) made is that session hijacking produces a flood
> of shit as you jam in packets in the hopes of getting the numbers
> right.  (Since the other guy is transmitting at the same time as you,
> you often send a slew of packets, to get them into the stack first.)
> There are a number of papers on detecting this sort of thing, many
> published in the months after Tsutomo was hacked.

Actually, the attacker does the _least_ amount of work, in terms of the
packet storms that result from hi-jacking a session.  The fundamental aspect
of hijacking revolves around de-syncing the state machine of the connection
between the two attacked hosts.

The "flood" you refer to is simply the result of the unsuspecting hosts
ACKing packets that are not in-line with the current sequence numbers that
THEY believe are correct.  Since the attacker (assumably) inserts
_something_ into the connection, the resultant SEQ/ACK pair will always be
different between the two unsuspecting hosts.  As the attacker continues to
insert data into the stream, the receiving host ACKs this data, but the
other end sees the ACK as out of bounds with its idea of the current state.
So, it just ACKs the ACK.  This perpetuates as ACKs answering ACKs.  Hence,
the eternal ACK storm.

What actually kills this ack storm is a lost packet.  Once one ACK is
dropped, the storm disappears.  This is a function of the network load and
reliablity of the the layer-1 medium.

So yes, you _can_ detect these ACK storms, but what you really want to see
in the packets you pick up is the idea of the desynchronized state machine.
Locating WHEN the desynch occured gives a little more information. Something
nobody really ever talks about in foiling/detecting all of these IP spoofing
attacks is to look at the layer-2 information of suspected forged attacks.
That and looking at packet IDs can give fairly certain proof that some clown
really is trying to do something evil.  Of course, proxys and bridges CAN
complicate things tho...  Granted that this analysis is in itself limited,
but all of the "hacking" tools out there TODAY just do simple Layer 3/4 forgings
-- and these are easy to detect.

-J.



Follow-Ups:
References:
Indexed By Date Previous: Re: Your Message Sent on Tue, 4 Nov 1997 11:56:45 +0530 (IST)
From: varmav @ verisign . com (Vik Varma)
Next: RE: Disabling LAN Manager on NT
From: Leonard Miyata <leonard @ geminisecure . com>
Indexed By Thread Previous: NT Server Security
From: jonathan tobin/DBK <dyabolyk @ dyabolyk . com>
Next: Re: Hijak detection
From: Adam Shostack <adam @ homeport . org>

Google
 
Search Internet Search www.greatcircle.com