[prev in list] [next in list] [prev in thread] [next in thread]
List: full-disclosure
Subject: Re: [Full-disclosure] TCP Hijacking (aka Man-in-the-Middle)
From: Oliver <olivereatsolives () gmail ! com>
Date: 2007-10-31 22:07:16
Message-ID: 5f03787b0710311507x11a9b20ck4bc97a5a9a389701 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I'd like to thank everyone for their responses. It took me a few days to
process all that and play around with those fancy tools. I think I hacked
this protocol, or at least manipulated it in a way it was designed not to.
It's likely that this is a trivial matter since the protocol is not used for
anything big and I'm only doing this for a class.
The protocol is text-based on top of TCP. It features a persistent TCP
connection, where once in a while the server pings the client with some
text, which has to respond with some text, and vice versa to make sure the
validity of the connection. I manipulated this by sending to the server some
pings and the client some pings, so that each party believes they are in
sync while they are really talking to me (no ack storm here either). The
number of pings for each was picked so that after this series of injected
packets, the sequence number of the server was out of sync by exactly the
amount of data that I want to send to the client (the spoofed packet), and
then I send it. This ensures that both sides believe they are in sync and do
not become disconnected at all, while the client has successfully accepted a
spoofed packet of mine.
I might sound like I'm repeating what was done 10 years ago. Has this been
done already (variations or attacks on application protocols)? What is it
called?
Thanks,
Oliver
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
>
[Attachment #5 (text/html)]
<p>I'd like to thank everyone for their responses. It took me a few days to \
process all that and play around with those fancy tools. I think I hacked this \
protocol, or at least manipulated it in a way it was designed not to. It's likely \
that this is a trivial matter since the protocol is not used for anything big and \
I'm only doing this for a class. </p><p>The protocol is text-based on top of \
TCP. It features a persistent TCP connection, where once in a while the server pings \
the client with some text, which has to respond with some text, and vice versa to \
make sure the validity of the connection. I manipulated this by sending to the server \
some pings and the client some pings, so that each party believes they are in sync \
while they are really talking to me (no ack storm here either). The number of pings \
for each was picked so that after this series of injected packets, the sequence \
number of the server was out of sync by exactly the amount of data that I want to \
send to the client (the spoofed packet), and then I send it. This ensures that both \
sides believe they are in sync and do not become disconnected at all, while the \
client has successfully accepted a spoofed packet of mine. </p><p>I might sound like \
I'm repeating what was done 10 years ago. Has this been done already (variations \
or attacks on application protocols)? What is it \
called? </p><p>Thanks,<br>Oliver</p><div><span class="gmail_quote"> On 10/25/07, \
<b class="gmail_sendername">Oliver</b> <<a \
href="mailto:olivereatsolives@gmail.com">olivereatsolives@gmail.com</a>> \
wrote:</span><blockquote class="gmail_quote" \
style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"> \
<p>Hello,<br><br>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? <br><br>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. <br><br>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. <br><br>Regards,<br>Oliver<br></p>
</blockquote></div><br>
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic