full-disclosure - Re: TCP Hijacking (aka Man-in-the-Middle)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 25 Oct 2007 10:27:04 -0700
From: Oliver <olivereatsolives@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: TCP Hijacking (aka Man-in-the-Middle)

Ouch.

Have some mercy on a second year computer engineering student? :)

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

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/