TCP/IP Sequence Number Analysis

johnwbyrd writes "Upon connection via TCP/IP to a host, the host generates an Initial Sequence Number (ISN). It's important to design ISN generation sequences so remote attackers can't predict an ISN (this is called a "blind spoofing" attack). Using phase space analysis you can check the quality of ISNs generated on various OSes. Windows 98's graph is quite pretty."

Comments

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Already Slashdotted....

[joshv]

Yeah, the bozos that created page put the entire report, with some 40-50 embedded images on one page. So everyone that hits the things tries to pull down many megs if image files all at once.

To summarized the report. Unpatched versions of NT4 and Windows 95/98SE are the most vunerable to spoofing attacks because of predictable patterns, or attractors, in the sequence produced by the random number generator used for ISNs. Linux,OpenBSD and FreeBSD scored near the top, though the report says there is room for improvement. Windows 2000, MacOSX, IRIX and BSDI were in the middle of the pack. HPUX and AIX were just as bad as windows 98.

So we have out prototypical 'windows less secure than linux' submission and the slashdotters are happy :)

-josh

Images at the Wayback Machine.

[ahaning]

http://web.archive.org/web/20010605064202/http://r azor.bindview.com/publish/papers/tcpseq/funct.jpg
http://web.archive.org/web/20010605044549/http:// r azor.bindview.com/publish/papers/tcpseq/mix.jpg
h ttp://web.archive.org/web/20010605045958/http://r azor.bindview.com/publish/papers/tcpseq/mix2.jpg
http://web.archive.org/web/20010605035655/http://r azor.bindview.com/publish/papers/tcpseq/linux.jpg
http://web.archive.org/web/20010605064823/http:// r azor.bindview.com/publish/papers/tcpseq/win2k.jpg
http://web.archive.org/web/20010605040907/http:// r azor.bindview.com/publish/papers/tcpseq/winnt.jpg
http://web.archive.org/web/20010605070134/http:// r azor.bindview.com/publish/papers/tcpseq/win95.jpg
http://web.archive.org/web/20010824220456/http:// r azor.bindview.com/publish/papers/tcpseq/win98.jpg
http://web.archive.org/web/20010605051434/http:// r azor.bindview.com/publish/papers/tcpseq/cisco2.jpg
http://web.archive.org/web/20010828165152/http:/ /r azor.bindview.com/publish/papers/tcpseq/cisco.jpg
http://web.archive.org/web/20010604211355/http:// r azor.bindview.com/publish/papers/tcpseq/aix.jpg
h ttp://web.archive.org/web/20010605063344/http://r azor.bindview.com/publish/papers/tcpseq/freebsd.jp g
http://web.archive.org/web/20010605052241/http: //r azor.bindview.com/publish/papers/tcpseq/openbsd.jp g
http://web.archive.org/web/20010605050747/http: //r azor.bindview.com/publish/papers/tcpseq/obsdnew.jp g
http://web.archive.org/web/20010605064736/http: //r azor.bindview.com/publish/papers/tcpseq/hpux11.jpg
http://web.archive.org/web/20010605061712/http:/ /r azor.bindview.com/publish/papers/tcpseq/sol7.jpg
http://web.archive.org/web/20010605062854/http://r azor.bindview.com/publish/papers/tcpseq/sol8.jpg
http://web.archive.org/web/20010605055059/http://r azor.bindview.com/publish/papers/tcpseq/sol2.jpg
http://web.archive.org/web/20010605060640/http://r azor.bindview.com/publish/papers/tcpseq/sol2ip.jpg
http://web.archive.org/web/20010605044904/http:/ /r azor.bindview.com/publish/papers/tcpseq/bsdi.jpg
http://web.archive.org/web/20010605070105/http://r azor.bindview.com/publish/papers/tcpseq/irix.jpg
http://web.archive.org/web/20010605042650/http://r azor.bindview.com/publish/papers/tcpseq/macos1.jpg
http://web.archive.org/web/20010605041254/http:/ /r azor.bindview.com/publish/papers/tcpseq/macos.jpg
http://web.archive.org/web/20010605054335/http:// r azor.bindview.com/publish/papers/tcpseq/dnslibc.jp g
http://web.archive.org/web/20010605061755/http: //r azor.bindview.com/publish/papers/tcpseq/dnswin.jpg
http://web.archive.org/web/20010605060741/http:/ /r azor.bindview.com/publish/papers/tcpseq/dnssol.jpg
http://web.archive.org/web/20010605051819/http:/ /r azor.bindview.com/publish/papers/tcpseq/comp.jpg
http://web.archive.org/web/20010605053816/http://r azor.bindview.com/publish/papers/tcpseq/random.jpg
http://web.archive.org/web/20010605053140/http:/ /r azor.bindview.com/publish/papers/tcpseq/data.jpg
http://web.archive.org/web/20010605044549/http://r azor.bindview.com/publish/papers/tcpseq/mix.jpg
h ttp://web.archive.org/web/20010824145421/http://r azor.bindview.com/publish/papers/tcpseq/linc.jpg
http://web.archive.org/web/20010605064500/http://r azor.bindview.com/publish/papers/tcpseq/ttime.jpg

Remove the spaces, copy-and-paste. We don't want to take the Internet Archive down, as well.

Not a new problem

[scotfl]

The idea of predicting Initial Sequence Numbers isn't exactly new, RFC1948: Defending Against Sequence Number Attacks was issued in 1996. Heck, even RFC793: Transmission Control Protocol from 1981 states:

When new connections are created, an initial sequence number (ISN) generator is employed which selects a new 32 bit ISN. The generator is bound to a (possibly fictitious) 32 bit clock whose low order bit is incremented roughly every 4 microseconds.

Which would provide somewhat random ISNs. What we are seeing here is the fact that compuers today are faster than they where twenty years ago, and thus better random (or psuedo-random) ISN generators are needed. Still it's nice to see vendors getting called out on bad implementations.

Re:Hmm.

[GigsVT]

echo r00t::0:0:0wned:/root:/bin/bash fits in one packet.

Food for thought.

More recent results?

[Westacular]

This report was published over a year ago, examining vulnerabilities that have been well-understood for >6 years. How is this news?

It might be useful if it was up to date, however as it stands most of the OSes listed there have had non-trivial revisions and new releases since then: WinXP isn't mentioned; Linux testing is limited to some version of 2.2, with no mention of 2.4; it refers to OpenBSD 2.9 coming out "soon" (3.1 is now available); OS X has had many major improvements since its first release; etc.

The BSD's

[Foxman98]

I'll be the first to admit that some of that articale was a little beyond me at this time. However, for anyone running a server, it would seem that OpenBSD still is the best choice for anything on the 'net. OpenBSD had the best TCP/IP random number generation (recently re-written). It has also been developed with security in mind. After about 4 years of linux experience it took me an hour to get an openbsd machine running, natting, and pf'ing. It was really that simple - as long as you have the experience. Want httpd installed? "make install" in the ports directory.

What really suprised me in this article is that some of the commercial unices were so poor in their implementation. Solaris was only secured after tweaking, Mac OS X, while not 100% attackable, still wasn't much better. Same for IRIX and AIX. I didn't notice version numbers however, does anyone know if the state has changed for newer version of IRIX? It was also disappointing the the 2.2 series kernel was used - have things changed in 2.4? If not, is there work being done in 2.5/6 ?

And if anyone has ANY insight as to why Window98 is much worse than windows95 I'd love to hear it.

Also available, cache of the pdf

[morcheeba]

All the pictures are included in this pdf mirror: http://www.mirrors.wiretapped.net/security/info/pa pers/networking/strange-attractors-and-tcpip-seque nce-number-analysis.pdf [1MB].

It doesn't display correctly with my version of KDE's PS/PDF Viewer, but good old ghostview works great.

Here is an (almost) complete Mirror.

[Cybersonic]

Mirror: http://ralph.cx/tcpseq/

Im missing 3 images... for now...

Re:For those wondering how insecure Microsoft is .

[FreeUser]

And also, I happened notice how you specifically failed to mention the reasonable improvements made in recent versions of Windows - specifically how its around ~10% attack feasability compared to 100% with older versions.

You mean, like this improvement?

Windows 95 sequence numbers are very weak. But it is really difficult to understand is why this algorithm was further "weakened" in Windows 98 (SE), decreasing estimated error and number of elements required to get the right guess, in average, 99.488%.

Seriously, the post was entitled "for those wondering how insecure Microsoft is", not "for those wondering how Microsoft stacks up against other systems" which, as you point out, would indicate that consumer OSes are pathetic, while 'professional' OSes like NT and 2000 are making modest improvements, and that while the *BSDs are pretty good, and GNU/Linux quite good, there are plenty of older UNIX implimentations that were quite poor, and even pathetic, as well, not to mention CISCO, which makes up much of the internet backbone.

But, since Microsoft is conducting a wholesale attack on our very freedom of choice through it Palladium and DRM efforts, pointing out additional, purely technical reasons for moving away from Microsoft to *BSD and GNU/Linux alternatives and thereby protecting your security as well as your freedom isn't such an ignoble thing to be doing at all.

Re:Hit them. Hard.

[Anonymous Coward]

Look, I browsed through the article, but not enough to quibble over the mathematical definition of attractors. I don't know enough about attractors to quibble even if I did.

But I am a statistician, and about the "vague pseudomathematical babble":

Sometimes, when you're presenting stuff to nonspecialists, you need to be a little more vague and pseudomathematical for people to understand. Sometimes it's more important for 100% of the people to get a 80% valid understanding of something than 20% to get a 100% valid understanding. I think it's more accurate in this regard to describe many vague mathematical generalizations as "quasimathematical".

Just being a little vague is ok or even necessary sometimes. The problem with always using "well-agreed mathematical definitions" is that not everybody understands them. There are, however, some who might understand the gist of the argument, and sometimes it's more important to get that across.

Maybe you're of the opinion that we shouldn't explain math to people who don't understand every bit of it known to mankind. I don't believe, though, that people who try to make math a bit more accessible should be "hit hard". On the contrary--they should be encouraged. People pursue things, after all, because they're interested in it, and often, we're interested in the things that are novel to us.

Again, I don't really know enough about it. Maybe this guy was completely incorrect. But quasimathematical babble isn't always bad.

It Is Called Research, and it Takes Time

[FreeUser]

I wonder how it came to be that you didn't publish the only meaningful indications of Microsoft's security? Oh, I know. It's because they are about 1/6th as bad as the outdated versions you impartially decided to cite.

That may be, but probably isn't, true.

If you read the article carefully you'll notice that the versions of *BSD and the Linux kernel (2.2.x) are also outdated. This isn't some neferious plot to diss Microsoft (hell, that isn't all that hard to do with cold, hard, factual data in the first place, so there is no need for anyone to cook the data, least of all this study), it is a result of the fact that research and study take time.

I'm sure if the author had looked at Linux 2.4.x and current versions of the BSDs the results would have been significantly better (Mac OS X as well, being a BSD derivative).

As for whether or not the various Windows versions would have been better, that is an assumption we really cannot make. Not for any prejudicial reasons, but because historically they generally haven't always improved, and indeed on at least one occasion (95->98) got considerably worse. We can hope that the security of Windows 2k has improved since then, but there is no real historical precendence to support that hope, in contrast with most other competitors products including the BSDs and Linux products cited here.

The comparison was fair: it was a snapshot of the state of the art taken a couple of years ago, then studied and analized in detail over those past two years. This is how every study that bases itself on factual research works, as opposed to corporate marketing drivel purchased to look like research, as has come from the Microsoft camp on numerous occasions in the last couple of years, and has in every case been thoroughly, and utterly obliterated in public rebuttal.

Re:For those wondering how insecure Microsoft is .

[FreeUser]

The thing I don't understand is... why do people continue to compare nowadays linux (or IRIX, Solaris, *BSD) etc... to things like Win98, which is _over 4 years_ old by now

The data that was studied for the last two or three years was collected prior to the study commencing, i.e. at least two or three years ago. If you'd bothered to read the paper, you would have noticed that the versions of *BSD and Linux being compared are equally as old (kernel 2.2.x of Linux, for example).

When you conduct a scientific study (not to be confused with the marketing drivel often sold as science and frequently purchased by the likes of Microsoft, and just as frequently disgraced and utterly rebutted a few days later by the scientific community) you collect the data, then you analize the data and draw conclusions from that data. All of that takes time, so any rigorous study conducted is going to be working with data collected at some time in the past.

[opinion]
I'm sure a study will come out showing the appalling weaknesses of Windows XP, but such a study will likely be reviled by Microsoft enthusiasts because, by the time the rigorous work is done, there will be some newer, even more invasive and buggy release of Windows out. That will not, however, make the study any less valid or accurate, any more than it would the study conducted here.
[/opinion]

Re:TCP/IP Sequence Number Analysis

[einhverfr]

Well, I agree to a large extent. But ISN attacks are not really all that common (though from a DoD perspective, they REALLY need to be prevented).

Of course, in general, SSL should prevent these sorts of attacks because the incoming payload would be expected to be encrypted and so it would be non-trivial to input packets into the stream and have them do anything other than DoS. Still a problem but not as much as other issues.

Again, I see this as an issue where competent attackers may be heavily targetting a given system, but it is unlikely to be used by the casual crowd. So the Win 95 and 98 crowd should be relatively safe, while the DoD NEEDS additional protection. Corporate infrastructures are in the middle, and it is probably a good idea to protect them against this sort of attack.

However, it is also a pretty serious refutation of "open source is insecure."

Re:OLD AND SILLY

[stripes]

Now SSH does prevent this, because you can still forge TCP/IP headers and guess ISNs, but you can't fake the encryption without knowing the password (and if you knew that, you'd just log in normally.)

SSH V1 in some modes did not prevent this (well, the unencrypted mode for sure didn't!). The DES mode at least could be forced to resync if you sent a lot of data...maybe 2^40 bits. This attack was actually succesfully used and somewhat publisized about 2 years ago...maybe 3. It only worked because the fellow who was attacked went away on a confrence and left an ssh session up and the attackers had 4 days to pump laots of data across. Definilty not a "low hanging fruit" attack!

I don't really know if SSH V2 prevents it, I have not really looked closley at the V2 protocal (unlike V1 where I wrote a Java client). Maybe someday...maybe when I need to learn another new language...

Not recently rewritten.

[Inoshiro]

"OpenBSD had the best TCP/IP random number generation (recently re-written)."

Didn't you question anything when they said 2.2.1x, or OpenBSD 2.8 was "recent"? No? OpenBSD 3.1 is the most recently released one. They've had this for quite a few releases now (didn't you also notice that OpenSSH's default root problem affected OpenBSD 2.9-3.1?). They also had *no* data for Linux 2.4, or Windows XP.

Don't believe me? Scroll down to the bottom of the page where it mentions it was last updated in April 2001.

Re:For those wondering how insecure Microsoft is .

[markmoss]

why do people continue to compare nowadays linux (or IRIX, Solaris, *BSD) etc... to things like Win98, which is _over 4 years_ old by now

Maybe because lots of people are still using Win98 - for economic reasons, because of a need to support old software needed to access critical data, or because considering microsoft's track record so far we tend to assume that in a few years it will be discovered that XP has even worse holes... Or people just don't like WPA, and assume that it's a future revenue enhancement tool - in a few years when MS has a replacement for XP on the market, their site for XP WPA might suddenly have all sorts of problems until people start giving up and buying a new OS when their systems crash and have to be reloaded.

I agree, comparing Win98 to server OS's like BSD isn't fair - there should be two separate comparisons, desktop to desktop and server to server. I gather that in server software, Win2K isn't bad in comparison to other commercial server products, but the OSS products (Linux and BSD) are far better. So Microsoft's bellyaching about OSS being insecure is proven wrong. (And if Linux has improved that much in the last 4 years, it's another indication that when security becomes important, open source can improve much faster than closed.)

As for comparing desktop to desktop, it's hard to arrange a comparison that everyone would agree is fair. First off, you don't exactly have competing desktop OS's - you have MS which writes desktop OS's and tries to upgrade them to run servers later, and you've got everything else (since Mac OS 9), which are *nix server OS's downgraded to run a desktop. It's something for MS to whine about when they lose. Anyhow, MS's latest desktop (XP Home) might have acquired a good sequence randomizer to plug this one hole, but the default installation apparently opens up a lot of others. I wonder how many other utterly brain-dead decisions like allowing Plug-n-Play to work across the network are not yet revealed...

Re:Hmm.

[mindstrm]

Well..
that's why you don't run any services that depend on the IP layer for authentication.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Stup[id plug.

[mindstrm]

Before everyone goes off about security.

TCP was not designed to be secure. It was designed to ensure data is put back in the proper order at the remote end, and to be able to adjust it's transmission to deal with congestion.

Yes, there is a security issue.... but any security breach through ip spoofing is really a fault of the higher layer application/protocol and NOT of the ability for a tcp session to be spoofed.

Before people get too gleeful...

[Lars T.]

The paper talks about a n-dimensional space, but only looks at the 3-dimensional case. It is totaly possible that the picture looks different at other dimensions (even at two), and spoofing works better when you use that as a basis. Which of course doesn't make the others more secure should they have better results at other dimensions - the worst case is still the worst case.

Re:What about NAT?

[moogla]

Absolutely. It seems that's the only reliable way of doing it anyway. If two nodes behind the firewall both open connections to a web server with the same ISN, whats the firewall to do? Actually, since it's the firewall that opens the connections on the behalf of the nodes behind it, surely code reuse dictates the packet headers have OpenBSD ISNs. Finally, the FAQ on the Netcraft Survey talks about this to explain why some webservers are "Microsoft IIS" running on Linux; what it's really seeing is the ISN characteristics of a linux firewall or load balancer in front of the webserver.

So I think you're safe :-D