Date: Sun, 28 Oct 2007 13:47:33 -0700
From: Oliver <olivereatsolives@...il.com>
To: "Mike Frantzen" <frantzen@....org>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: TCP Hijacking (aka Man-in-the-Middle)

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 <frantzen@....org> 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 <olivereatsolives@...il.com> 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
> >
> >
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists