Vulnerability Development mailing list archives
Re: Forge packets ?
From: Michael Wojcik <Michael.Wojcik () MERANT COM>
Date: Thu, 14 Sep 2000 06:38:45 -0700
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
Current thread:
- Forge packets ? Skreel (Sep 12)
- Re: Forge packets ? Samy Kamkar [CommPort5] (Sep 12)
- Re: Forge packets ? FX, Phenoelit (Sep 21)
- <Possible follow-ups>
- Re: Forge packets ? Skreel (Sep 12)
- Re: Forge packets ? Samy Kamkar [CommPort5] (Sep 12)
- Re: Forge packets ? Michael Wojcik (Sep 12)
- Re: Forge packets ? George Gales (Sep 12)
- Re: Forge packets ? Everhart, Glenn (FUSA) (Sep 12)
- Re: Forge packets ? Samy Kamkar [CommPort5] (Sep 13)
- Re: Forge packets ? Andrew Thomas (Sep 13)
- Re: Forge packets ? Michael Wojcik (Sep 14)