Full Disclosure mailing list archives
Re: TCP Hijacking (aka Man-in-the-Middle)
From: Oliver <olivereatsolives () gmail com>
Date: Thu, 25 Oct 2007 10:27:04 -0700
Ouch. Have some mercy on a second year computer engineering student? :) On 10/25/07, reepex <reepex () gmail com> wrote:
Hi I am sorry to hear you just woke from your coma. It is now 2007 not 1995. On 10/25/07, Oliver <olivereatsolives () gmail com> wrote:Hello, I have been searching all over the place to find an answer to thisquestion,but Google has made me feel unlucky these last few days. I hope I couldfindmore 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?Isit theoretically possible to not reset the connection with the server ortheclient, but play the man-in-the-middle attack? An example network scenario of this that I could come up with is thatthehacker is within the same network as the victim (client), who isconnectedto 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) totheserver 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 andviceversa, using the seq/ack numbers that they would accept. While thisseemspretty pointless so far, the hacker could inject messages at will toeitherside of the connection, and still make the server and client believethatthey are in sync with each other ( i.e. this would not work if thehackerdoes not relay the messages with the seq/ack numbers the server andclientwould accept). That means the hacker goes undetected and could dowhateverhe 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 theTCPprotocol 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 ordismissthis 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/
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- TCP Hijacking (aka Man-in-the-Middle) Oliver (Oct 25)
- Re: TCP Hijacking (aka Man-in-the-Middle) reepex (Oct 25)
- Re: TCP Hijacking (aka Man-in-the-Middle) Oliver (Oct 25)
- Re: TCP Hijacking (aka Man-in-the-Middle) Valdis . Kletnieks (Oct 25)
- Re: TCP Hijacking (aka Man-in-the-Middle) 3APA3A (Oct 25)
- Re: TCP Hijacking (aka Man-in-the-Middle) Valdis . Kletnieks (Oct 25)
- Re: TCP Hijacking (aka Man-in-the-Middle) 3APA3A (Oct 26)
- Re: TCP Hijacking (aka Man-in-the-Middle) Valdis . Kletnieks (Oct 26)
- Re: TCP Hijacking (aka Man-in-the-Middle) 3APA3A (Oct 26)
- Re: TCP Hijacking (aka Man-in-the-Middle) Valdis . Kletnieks (Oct 26)
- Re: TCP Hijacking (aka Man-in-the-Middle) don bailey (Oct 26)
- Re: TCP Hijacking (aka Man-in-the-Middle) reepex (Oct 26)
- Re: TCP Hijacking (aka Man-in-the-Middle) 3APA3A (Oct 25)
- Re: TCP Hijacking (aka Man-in-the-Middle) reepex (Oct 25)