On Thu, 28 Dec 1995, Darren Reed wrote:
> > This is tough, since we can really predict bit for bit what the headers
> > of the ACK packet that we need to send are...
>
> It isn't really that hard.
>
> The session being hijacked will, at one end, experience a larger number of
> ACKs than it would if it weren't there. Also, the "real" ack's would
> indicate that one end of the connection wasn't sending data (the SEQ
> number wouldn't be changing).
>
> However, to be able to do this, successfully, you're going to need to
> cache TCP datagrams with suspect ACK/SEQ numbers in case they happen to
> be correct. A large number of these conflicts would be a dead giveaway.
I can see this, but there is a problem. In order for this to work, a
hijack must have started, and is probably 2 or 3 packets already
underway. By this time it might be too late. An attacker can insert ONE
carefully constructed ACK (w/ data) packet into the stream w/ "bad" data
and that's all that's needed.
I would really only consider this a partial solution to the problem, and
if someone (the attacker) figured out that this is what the progam was
doing, they could then easily circumvent that as described above, unless
*I* am missing something?
Brain21
Follow-Ups:
|
|
