Thanks for all the great resources. That took me quite a few days to digest and play with.
I am not deploying this in a switched environment. It's for a demo and the victim's machine is a virtual machine in VMware hosted on the attacker's machine (mine). The victim's connection is through VMware's NAT. So in essence, I would be able to view packets, but unable to ARP spoof (unless I could do that locally - arp spoof myself? which is Windows by the way). Mike, you said that there would be an ACK storm. I saw that. The connection was reset about a minute later - probably because the server did not receive responses from the client (victim) and the connection timed out. Is there something back about ACK storms? Can I not reply to all the packets since the application protocol is simple enough? There are even some simple application ping commands that I could use to re-sync the seq numbers. But would the ACK storm cause any trouble in that sense? Thanks, Oliver On 10/25/07, Mike Frantzen <[EMAIL PROTECTED]> wrote: > > It would cause a ACK storm. If you can sniff the connection and if the > connection uses TCP Timestamps (RFC1323) then you can hijack the connection > really easily. You take advantage of PAWS (Protection Against Wrapped > Sequence numbers). In every packet you send the other guy your timestamp > and he always echoes it back to you. If the other guy echoes a timestamp > too far in the past or in the future then you reject the packet (it has to > do with really high speed connections, read the RFC). > To hijack you just send both endpoints a packet with a drastically > increased timestamp. All of their packets in the future will echo your > spoofed timestamp instead of the real timestamp and the real destination > will drop the packet. That leaves you free to relay whatever you like. > > It's a little more complicated in practice. Smacking the network switch > hard enough that you can see all of the traffic is going the be the trick. > Do they even manufacture hubs anymore? > > .mike > > On 10/25/07, Oliver <[EMAIL PROTECTED]> wrote: > > > > Hello, > > > > I have been searching all over the place to find an answer to this > > question, but Google has made me feel unlucky these last few days. I hope I > > could find more expertise here. The burning question I have been pondering > > over is - could TCP connections be hijacked both ways? I know there are > > tools ( e.g. Hunt) that sniffs traffic and could arbitrarily reset a > > connection by spoofing the IP and MAC address. But could there be more than > > just that? Is it theoretically possible to not reset the connection with the > > server or the client, but play the man-in-the-middle attack? > > > > An example network scenario of this that I could come up with is that > > the hacker is within the same network as the victim (client), who is > > connected to a server through a persistent TCP connection. Now the hacker > > could pretend to be the server and send a TCP message (not reset/fin) to the > > client and change the seq/ack numbers on the client side, and the hacker > > could pretend to be the client and send a TCP message (not reset/fin) to the > > server and change the seq/ack there. Thus, the seq/ack numbers are > > completely out of sync for the client and server and thus would not > > recognize each others messages. At this point, the hacker could relay ( > > i.e. be man-in-the-middle) the messages from the client to the server > > and vice versa, using the seq/ack numbers that they would accept. While this > > seems pretty pointless so far, the hacker could inject messages at will to > > either side of the connection, and still make the server and client believe > > that they are in sync with each other ( i.e. this would not work if the > > hacker does not relay the messages with the seq/ack numbers the server and > > client would accept). That means the hacker goes undetected and could do > > whatever he chooses, as he has "hijacked" the connection. > > > > Is this possible? Assuming there is no hardware limitation (e.g. > > router/switch blocking MAC/IP addresses from certain port). Would the TCP > > protocol definition and implementation in Windows and *nixes these days > > would interpret this behaviour correctly (correctly for the hacker, > > incorrectly for themselves)? I imagine it would be quite a bit of work > > proving this theory and perhaps some of you could enlighten me or dismiss > > this concept. > > > > Regards, > > Oliver > > > > >
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
