1. Introduction
1.1 Current risks of TCP/IP
spoofing
2. New
evidence
3.1 Windows
3.2 IRIX
3.3
Netware
3.4 Cisco IOS
3.5 Solaris
3.6 *BSD
family
3.7 MacOS X
3.8 UNICOS
3.9
Tru64
3.10 HPUX
3.11 OS/400
3.12 NextSTEP
3.13 AIX
3.14
OpenVMS
3.15 OS9
4. Conclusions
5. Credits
1. Introduction
Over a year ago, I published a whitepaper
titled "Strange
Attractors and TCP/IP Sequence Number Analysis" - an attempt to evaluate
TCP/IP sequence number generators in several mainstream operating systems by
mapping the dynamics of the generated sequence numbers into a three-dimensional
phase space. We demonstrated how this approach can be used to find many
non-trivial correlation, and discussed why the results can be directly used to
perform actual ISN prediction. This research, among with the research from
Guardent, resulted in the release of CERT Advisory
CA-2001-09 and several vendor bulletins.
The goal of this follow-up is to evaluate any subsequent security measures
implemented by the vendors in this field since the release of the original
publication, and to evalute several systems that were not covered earlier. For
the purpose of this document, we assume that the reader has read the original
publication, and has an understanding of the methodology and terminology used.
Please note that the presented results are preliminary and should not be
considered as a reliable metric for comparing the relative strength of the
operating systems ISN generators at this time.
2. Current risks of TCP/IP spoofing
While the situation has greatly improved
since the days when Kevin Mitnick used a TCP/IP spoofing attack to break into
Tsutomu Shimomura's machine, and while the r* protocols or telnet logins over
public networks are almost completely extinct, the importance of providing good,
unpredictable TCP ISN numbers is downplayed by many. The majority of the
Internet traffic is still unencrypted, and much of this data can be considered
high-profile, even if it does not contain sensitive information as such. Here
are several most obvious attack vectors:
3. New evidence
In this section, we review a number of
operating systems that were either identified as not satisfactory in the
original publication, or were not covered by our research at the time. Several
systems, such as Linux, use the same, satisfactory ISN generator as the one used
a year ago, and because of that, are not covered here in any more detail.
3.1 Windows
In the original publication, we reviewed the
ISN generator in Windows 2000 and NT4 SP6a, and found it hardly sufficient for
the current needs, considering the bandwith available to a typical attacker and
other important factors. Quoting the original document:
"Windows 2000 and Windows NT4 SP6a are presenting almost the same level of
TCP sequence number predictability, which can be qualified as medium to high,
allowing attacker to get reasonably high success rates without using excessive
amounts of network resources."
One year later, we find that both Windows 2000 SP2 and Windows XP still use
essentially the same ISN generator:
This ISN generator does not provide a sufficient protection against targeted
high-profile attacks. The code does not seem to use RFC1948 to minimize the
potential impact. RFC1948, proposed by Steve M. Bellovin, is an attempt to
differentiate ISNs used for each host. This is done using one-way MD5 shortcuts
in a way that reduces the impact of non-random sequence numbers to only one
source-destination IP pair.
3.2 IRIX
IRIX 6.5.15 provides two settings, tcpiss_md5
set to zero - insecure mode - and tcpiss_md5, a secure mode that is supposed to
implement strong randomness. With this setting set to zero, results are
extremely trivial to crack:
Unfortunately, tcpiss_md5 setting does not seem to provide much security
either. It does not properly implement RFC1948, and sequence numbers for
different hosts are roughly the same. Data collected by one host can be used to
attack another. The attack feasibility is reasonable, with 25% success ratio in
our 5,000 element test.
The attractor above is essentially a different view of the one we published
in the original paper. This is interesting in the light of a premilinary
statement from SGI that this feature does prevent the attack described by CERT.
The name of this setting seems to suggest that MD5 is used in the
implementation, but the output does not indicate that any significant portion of
MD5-hashed data is used.
We contacted SGI about this problem. SGI users should expect a patch and an
official advisory coming soon.
3.3 Netware
At first sight, Netware 5 and 6 appeared reasonably robust, providing
approximately 24 bits of randomness. This result was confirmed by a trivial nmap
test:
But when we took a closer look at the picture, we noticed that almost all
points are excessively saturated, and that the coverage of the 24 bit space is,
in fact, very poor. Further tests confirmed that, while Netware uses "random"
deltas to generate subsequent ISNs, it appears that the random number generator
is badly broken in that it constantly returns a small subset of randomly looking
increments / decrements in a short cycle. Our tool was able to make correct
guesses in 90% of the cases. Further analysis showed that Netware does not
implement RFC1948 to minimize the impact of this issue.
After being contacted in the course of writing this paper, the Netware
developers contacted us promptly, providing us with a sample of the new ISN
generator that is supposed to solve the issue:
The attractor does look very interesting, suggesting that some randomness was
added to less random output, perhaps the old generator, still leaving some gaps
in the space, but the amount of this randomness is sufficient to make the attack
not feasible, with approximately 30 bits of randomness present. This generator
will be implemented in Service Pack 3, yet to be released.
Please note that use of the "packet signature" feature in Netware can
minimize the exposure with previous versions. For more details, please refer to
this
or this
URL at novell.com.
3.4 Cisco IOS
We tested the Cisco IOS 3640 running IOS
12.2.10a. It appears that the
fix implemented by Cisco performs well, delivering a 32-bit randomness. Our
approach did not deliver meaningful results, and the implementation scored very
well:
3.5 Solaris
Our initial analysis seems to indicate that
Solaris 9 is using essentially the same level of TCP ISN protection as Solaris 8
- with the first setting, tcp_strong_iss set to 0, providing no randomness at
all (feasibility: 100%), the default setting of 2 providing some medium
protection (feasibility: 3%), and tcp_strong_iss set to 2 implementing RFC1948.
Further investigation is necessary for tcp_strong_iss=2, a setting that had a
slight but possibly fatal flaw caused by having a static secret used in its
RFC1948 implementation to determine whether this issue is still present. Please
refer to the original publication for more details about the issue.
We were unable to obtain Solaris 9 samples gathered from a Linux box that was
used to generate the original evaluation. The importance of using the same test
system is that different systems use a different range and ordering of source
ports for outgoing connections, and that will affect the particular flaw
discussed originally. We were able to get results obtain results gathered from
another Solaris system that may indicate the issue was at least partly addressed
by Sun:
3.6 *BSD family
The code that is now being used in FreeBSD and other *BSD systems (except for
BSDI, which we hadn't have a chance to test here) seems to be very good,
providing a clean, 32-bit randomness. As Mike Silbersack pointed out, the code
is not exactly the same, but all implementations generate comparable results.
3.7 MacOS X
MacOS X scored rather poorly in the original
test, but its PRNG has been significantly improved since then. Current results
show an uniform, random 31-bit cloud:
3.8 UNICOS
The following results are from UNICOS
10.0.0.8 running on Cray SV1:
This is a very interesting case that gives attack feasibility around 10% in
our test. The UNICOS PRNG implementation is rather poor, but the attractor shows
a complex nature in this algorithm. It is probably a very good candidate for
further investigation, and perhaps some analysis in more than three dimensions,
which we leave as an exercise to more curious readers.
3.9 Tru64
The following results are from Tru64 5.1A:
This is a very trivial attractor. A close-up of the attractor reveals that
every single point on this picture is actually a very small cloud:
This indicates there is some randomness - but the amount is so insignificant,
the results are 100% predictable in 5,000 attempts.
3.10 HPUX
HPUX11 scored poorly in our original test. A
patch was released (PHNE_26771) that is supposed to fix weak ISN problems and
implement RFC1948. The functionality is not enabled by default, and the
resulting sequence numbers are of mediocre quality:
Once turned on, the generator implemented in PHNE_26771 yields the following
results:
This seems to suffer from the same problem that was present in the Sun's
implementation of RFC1948 in Solaris 8. It appears that results for a given IP
are highly predictable over a longer period of time, making many IP reuse attack
scenarios feasible. On the other hand, such attacks are much more difficult to
perform and limited to some specific environments, so this is not a critical
issue.
3.11 OS/400
OS/400 yielded very surprising results. For
several minutes, it returned a numbers that while were not completely random,
seemed to display a non-trivial dependency. The "randomness" wasn't really
unpredictable, in that the PRNG seemed to generate same values over and over
again, generating a highly saturated attractor points and resulting in 100%
attack feasibility:
What was more surprising is that, after a while, apparently as a result of
receiving many subsequent connection attempts (approximately 20000), the numbers
have completely changed. OS/400 started to return a very long sequences of
exactly the same, low ISN number (113464), that, after some time, eventually
increased by one to start another long sequence of exactly the same nature. This
was still an issue long hours after finishing the test, and wasn't specific to a
single source IP address. It appears that OS/400 stack is broken, and can be
rendered more vulnerable to trivial attacks by a short SYN flood.
3.12 NextSTEP
NextSTEP uses trivially predictable sequence
numbers:
3.13 AIX
AIX 5.1 does not seem to deliver satisfactory
results:
3.14 OpenVMS
The following results come from OpenVMS V7.2
running on VAXstation 4000-60, with Compaq TCP/IP Services for OpenVMS VAX
Version V5.1 (the default TCP/IP stack). A clear and strong attractor is
visible, and overall ISN quality is low:
3.13 OS9
The following data comes from OS9 v2.3 - the
results are trivially predictable:
![[ Windows XP ]](newtcp_fichiers/winxp.gif)
OS Name:
Windows XP
R1 radius:
10
Average R2:
251
Average N:
179
Average error:
279
Attack feasibility:
12.00% ![[ IRIX tcpiss_md5=0 ]](newtcp_fichiers/irix-nomd5.gif)
OS Name:
IRIX 6.5.15 tcpiss_md5=0
R1 radius:
0
Average R2:
93
Average N:
297
Average error:
0
Attack feasibility:
100.00% ![[ IRIX tcpiss_md5=1 ]](newtcp_fichiers/irix-md5.gif)
OS Name:
IRIX 6.5.15 tcpiss_md5=1
R1 radius:
0
Average R2:
869
Average N:
43
Average error:
556
Attack feasibility:
25.00% ![[ Netware 6 ]](newtcp_fichiers/netware5.gif)
OS Name:
Netware 6
R1 radius:
10
Average R2:
2484
Average N:
11
Average error:
0
Attack feasibility:
90.00% TCP Sequence Prediction: Class=random positive increments
Difficulty=4636703 (Good luck!)
![[ new Netware ]](newtcp_fichiers/newnet.gif)
OS Name:
Netware 6 (SP3)
R1 radius:
100000
Average R2:
999
Average N:
34
Average error:
n/a
Attack feasibility:
0.00% ![[ IOS 12.2.10a ]](newtcp_fichiers/ios12.gif)
OS Name:
IOS 12.2.10a
R1 radius:
100000
Average R2:
1487
Average N:
25
Average error:
n/a
Attack feasibility:
0.00% ![[ Solaris ISS=2 ]](newtcp_fichiers/sol-iss2.gif)
OS Name:
Solaris 9 (tcp_strong_iss=2)
R1 radius:
1000000
Average R2:
118
Average N:
260
Average error:
120
Attack feasibility:
0.02% ![[ FreeBSD 4.6 ]](newtcp_fichiers/fbsd.gif)
OS Name:
FreeBSD 4.6
R1 radius:
1000000
Average R2:
101
Average N:
279
Average error:
n/a
Attack feasibility:
0.00% ![[ MacOS ]](newtcp_fichiers/macos.gif)
OS Name:
MacOS X
R1 radius:
1000000
Average R2:
118
Average N:
239
Average error:
n/a
Attack feasibility:
0.00% ![[ UNICOS 10.0.0.8 ]](newtcp_fichiers/unicos.gif)
OS Name:
UNICOS 10.0.0.8
R1 radius:
10
Average R2:
948
Average N:
47
Average error:
390
Attack feasibility:
9.00% ![[ Tru64 5.1 A ]](newtcp_fichiers/tru64.gif)
OS Name:
Tru64 5.1A
R1 radius:
0
Average R2:
742
Average N:
694
Average error:
405
Attack feasibility:
100.00% ![[ Tru64 5.1 A (zoom) ]](newtcp_fichiers/tru64_zoom.gif)
OS Name:
Tru64 5.1A
R1 radius:
0
Average R2:
742
Average N:
694
Average error:
405
Attack feasibility:
100.00% ![[ HPUX11 ]](newtcp_fichiers/hpux11.gif)
OS Name:
HPUX 11
R1 radius:
10
Average R2:
382
Average N:
113
Average error:
121
Attack feasibility:
2.00% ![[ HPUX11 pass ]](newtcp_fichiers/hpux-pass.gif)
OS Name:
HPUX 11 (passphrase set)
R1 radius:
100000
Average R2:
388
Average N:
145
Average error:
416
Attack feasibility:
3.00% ![[ OS/400 ]](newtcp_fichiers/os400.gif)
OS Name:
OS/400
R1 radius:
0
Average R2:
2499
Average N:
14
Average error:
0
Attack feasibility:
100.00% ![[ NextSTEP ]](newtcp_fichiers/next.gif)
OS Name:
NextSTEP
R1 radius:
0
Average R2:
833
Average N:
33
Average error:
0
Attack feasibility:
100.00% ![[ AIX ]](newtcp_fichiers/aix.gif)
OS Name:
AIX 5.1
R1 radius:
0
Average R2:
1999
Average N:
15
Average error:
0
Attack feasibility:
100.00% ![[ OpenVMS ]](newtcp_fichiers/openvms.gif)
OS Name:
OpenVMS V7.2
R1 radius:
10000
Average R2:
503
Average N:
2231
Average error:
0
Attack feasibility:
15.00% ![[ OS9 ]](newtcp_fichiers/os9.gif)
OS Name:
OS 9
R1 radius:
0
Average R2:
791
Average N:
37
Average error:
0
Attack feasibility:
100.00%