Ouch. Have some mercy on a second year computer engineering student? :)
On 10/25/07, reepex <[EMAIL PROTECTED]> wrote: > > Hi I am sorry to hear you just woke from your coma. It is now 2007 not > 1995. > > 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/ > > >
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
