It is difficult to generate unpredictable numbers using a computer. This
is because computers are designed to execute strictly defined sets of
commands in repeatable and accurate ways. Thus, every fixed algorithm
can be used to produce exactly the same results on another computer,
which then can be used to effectively predict output values, assuming
attracker can reconstruct internal state of such a remote system.
Also, even if the target PNRG function is not known, sooner or later
the algorithm will start generating the same exact sequences over again,
because there is a limited number of possible internal states that can
be used by a specific algorithm (computers are using finite precision and
range arithmetics). Hopefully this happens later and the conditions to
start the repeating of sequential numbers will take many months or years.
But, there are known vulnerable implementations with a PRNG generator
period of just over 500 elements or less.

The common approach of dealing with this lack of true randomness is to
introduce additional randomness, or entropy, from an external,
unpredictable source. Usually, this randomness is calculated from
keystroke intervals, specific I/O interrupts and other parameters that are not
known to the attacker. This solution, combined with a reasonably good hashing
function that produces full 32 or 31-bit data with no correlation
between subsequent results without revealing useful information about the
internal state of PRNG function, can be used to make an excellent TCP sequence
generator. Unfortunately, TCP ISN generators are rarely written this
way, and when they are, there are numerous flaws or implementation errors
that can lead to predictable ISNs.

RFC1948 suggests the use of source IP address, destination IP address,
source port and destination port, plus an additional random secret key.
This data should be hashed using a shortcut function to generate random
and unique sequence numbers for every unique connection. Failing to account
for this can lead to improper conclusions when analyzing TCP generators with
respect to ISN predictability. Indeed, statements that are true for the
ISNs coming back to the attacker might not be true for other
connections, as the hash values would be different.

This research attempts to analyze the pseudo-random number generators
(PRNGs) used for TCP sequence number generation in different operating
systems and to expose potential flaws in the algorithms used. We
analyzed the generated sequence numbers, instead of trying to focus
on the actual implementations in the various operating systems. In essence,
we approached the analysis from the same standpoint as the remote attacker
would - from the network.

The following is an example of input data from a sequence of ISNs.
Looking at the example doesn't allow us to determine what kind of underlying
function was used to generate the data. It appears that these numbers
are random with no dependencies between subsequent results:

What we see above is a trivial, probably microsecond clock-based time
dependency at its finest (see Appendix A), with most
of the points attracted to one point with "echos" around. In order to
exploit this vulnerability, the attacker would simply have to synchronize
his own clock with the IOS clock, taking care of packet rtt times, and
performing the attack at any time by sending packets for, e.g., 100
microseconds +/-. Thus, Cisco IOS can be qualified as a high-risk OS.
Besides that, our attractor analysis method provides reasonably high
success ratio using 5,000 guesses against this OS.

Here, for comparsion, are the results for patched IOS. The main
attractor is still there, but some additional noise was introduced to make the
prediction more difficult: