As many people will be aware, the Microsoft TCP/IP stack for NT 4.0 up to and
including SP3 used a simple "one-per-millisecond" increment for the initial TCP
sequence number. This was changed in SP4 to make the initial sequence number
generation less predictable. However I've found that, while the initial
TCP sequence
number pattern has changed from SP3 to SP4, it's still quite predictable.
The key features of the new SP4 pattern are:
a) It uses small positive increments between 0 and 14 inclusive;
b) The increment appears to always be an even number: 0, 2, 4, 6, 8, 12, 10
or 14;
c) The increment does not appear to be time-related - the pattern is the
same whether
the time difference between samples is 20ms or 1s.
An example of the observed behaviour is shown in the table below:
Sequence Number
Difference of occurrences
-------------- ---------------------
0 648
2 584
4 608
6 660
8 602
10 666
12 641
14 590
This data shows the distribution of differences between sequence numbers
from a total of 5,000 initial sequence number samples (i.e. 4,999 differences).
So for example, the difference between two consecutive initial TCP sequence
numbers was 10 in 666 out of 4999 sample pairs.
This data was gathered from a quiescent system on an Ethernet LAN. However,
it is similar to data that I have obtained from Internet-connected systems
such as
IIS Web servers.
While this new initial TCP sequence number pattern is different from the
old pre-SP4
behaviour, it is still quite easy to predict: the data above shows that
there are only
8 possible next-sequence numbers. Bearing in mind that most TCP/IP stacks
simply
ignore incorrect sequence numbers, it's easy to bracket the expected range with
a number of packets. Indeed, this new pattern may actually be easier to
predict than
the old behaviour over the Internet and other WANs because in this
environment, it's
probably easier to send a spread of 8 packets than to predict the packet
latency to
within 8 milliseconds over a long-haul connection.
The "correct" thing for a TCP/IP stack to do when generating initial TCP
sequence
numbers is to make them random as recommended in RFC1948. I've found that
many operating systems including Linux 2.x and Solaris 2.6 (when tcp_strong_iss
is set to 2) already do this, although there are still lots of stacks out
there generating
predictable initial TCP sequence numbers.
Microsoft's description of the NT SP4 sequence number change is in knowledge
base article ID: Q192292 "Unpredictable TCP Sequence Numbers in SP4".
I first discovered this new predictable TCP sequence pattern while performing a
penetration test for one of our customers who had recently changed from SP3 to
SP4. Microsoft have been informed of these findings and are currently
investigating
the situation.
I'll be putting more details up on the NTA Monitor Web site within the next day
or two, so for more information you can visit http://www.nta-monitor.com/
Roy Hills
NTA Monitor Ltd
--
Roy Hills Tel: +44 1634 721855
NTA Monitor Ltd FAX: +44 1634 721844
6 Beaufort Court, Medway City Estate, Email: Roy.Hills@nta-monitor.com
Rochester, Kent ME2 4FB, UK WWW: http://www.nta-monitor.com/
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:58:30 PDT