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@w4g.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@gmail.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
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
