Slashdot Mirror

← Back to Stories (view on slashdot.org)

TCP/IP Sequence Number Analysis

Posted by michael on from the you-don't-have-to-be-a-kreskin-to-predict-this dept.

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."

8 of 215 comments (clear)

  1. Re:Already Slashdotted.... by joshv · · Score: 5, Informative

    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

  2. Images at the Wayback Machine. by ahaning · · Score: 4, Informative

    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.

    --
    Withdrawal before climax is very ineffective and those who try this are usually called "parents."
  3. Also available, cache of the pdf by morcheeba · · Score: 5, Informative

    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.

    --
    HIV Crosses Species Barrier... into Muppets
  4. Here is an (almost) complete Mirror. by Cybersonic · · Score: 4, Informative

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

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

    --
    Cybie! aka Ralph Bonnell
  5. Re:OLD AND SILLY by stripes · · Score: 3, Informative
    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...

  6. Re:Hmm. by mindstrm · · Score: 3, Informative

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

  7. Stup[id plug. by mindstrm · · Score: 3, Informative

    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.

  8. Re:What about NAT? by moogla · · Score: 3, Informative

    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

    --
    Black holes are where the Matrix raised SIGFPE