Re: Forge packets ?

[Michael Wojcik <Michael.Wojcik () MERANT COM>]

> From: Samy Kamkar [CommPort5] [mailto:CommPort5 () LUCIDX COM]
> Sent: Tuesday, September 12, 2000 5:27 PM

> That sounds right, but as originally asked, can we send some data without
> disrupting anything...let's think about this situation.  We're assuming
that
> the remote host will take packets with incorrect sequence numbers, etc and
> throw them away (I doubt there's much else it would want to do with those
> packets.)

Hmm.  It should discard packets entirely below the currently ACK'd sequence.
However, if a packet arrives with a sequence that straddles the current ACK
number or starts after it, I think the receiver will generate another ACK to
tell the sender to resend starting at the last-ACK'd octet (since the ACK
specifies the next octet to send).  If the real sender and the hijacker are
both sending to the receiver, there will be a lot of ACKs flowing back, and
a lot of resending by the real sender.

And if the real sender gets lucky and sends a packet that begins where the
receiver expects it to, the real data will get inserted into the hijacker's
data.  This could reasonably happen with eg. an FTP large file transfer
where the packets are going to tend to be the same length, since presumably
the hijacker will also send packets of that length to stay synchronized.

>  See below and maybe you'll see how it can be done without disrupting
> anything:
>
> spoofed == us, local == the local user, remote == remote host...
> spoofed-local > remote: <data>  (here is what you want sent, but now local
> is out of sync)
> spoofed-remote > local: <data>  (this is just here to get local to
synchronize
> with our 'half-hijack'...we hope this will trigger local to send some
stuff
> back to 'remote' and synchronize like that)
> local > remote: ack/<data> (this is discarded at remote since remote
already
> got it's data)
> remote > local: ack

Here's the problem I suggested before: local may see an ACK from remote for
spoofed-local's data before local gets around to sending its data for that
part of the sequence.  local's stack might discard that out-of-order ACK, or
it might not.  I don't know what the appropriate standards say about this
(do the Host Requirements RFCs comment on it?), but the implementation in
eg. Stevens drops the connection (see figure 29.5 in _TCP/IP Illustrated_ v.
2) and increments one of the TCP statistics - so you've not only disturbed
the real connection and notified the user, you've left a trail for the
administrator.

In short, you're counting on not only getting the sequence numbers right,
but getting the timing right as well.  If you're in a position to have a
good chance of doing that, becoming an evil router is probably easier.

I think the only realistic option is man-in-the-middle for most
applications.  Someone mentioned in another message that hunt mounts a MITM
attack using ICMP redirects.

Transparently hijacking without preventing the real peers from communicating
directly is an intriguing idea, but in practice it looks very difficult, at
least after cursory inspection.

Michael Wojcik             michael.wojcik () merant com
MERANT
Department of English, Miami University