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

19 of 215 comments (clear)

  1. google cache by Anonymous Coward · · Score: 2, Informative

    http://216.239.39.100/search?q=cache:sJUlrsbgsJ4C: razor.bindview.com/publish/papers/tcpseq.html+&hl= en&ie=UTF-8&e=619

  2. Must be Sunday by Anonymous Coward · · Score: 2, Informative

    Let's see. Mitnick used this what, 8 years ago now? That's how he got into that guy's login session that was pre-existing between the two machines, or something to that effect.

    Plus, various folks were using this on big IRC networks after that, but still many years ago.
    That "emmanuel-" in #2600 that says he gave the subscription list to the FBI and ran over Walter was a spoof. So was billg in #windows95. That's just the tip of the iceberg.

    Everything old is new again.

  3. old news by Anonymous Coward · · Score: 1, Informative

    wasn't this already posted here like a year ago?

  4. Re:Google cache saves the day [ the correct link ] by Anonymous Coward · · Score: 2, Informative

    Pictures are bettererer.

    http://web.archive.org/web/20020124085843/http://r azor.bindview.com/publish/papers/tcpseq.html

  5. For those wondering how insecure Microsoft is ... by NASAKnight · · Score: 1, Informative

    Windows NT4 SP3
    Attack feasibility: 97.00%

    Operating system: Windows 98 SE
    Attack feasibility: 100.00%

    Operating system: Windows 95
    Attack feasibility: 100.00%

    --
    Fault loves the past, worry loves the future, but content enjoys the present.
  6. mirror by iamroot · · Score: 2, Informative

    Ok, I've mirrored the HTML and most of the images(still downloading) HERE. Please only download this to mirror it! My bandwidth is limited!

    1. Re:mirror by iamroot · · Score: 2, Informative

      STUPID NAMEZERO!!
      The mess up the URLS too much.
      http://galacticroot.dyndns.org/mirrors/tcpseq/tcps eq.html is the actual address of the mirror, not http://galacticroot.dyndns.org//mirrors/tcpseq/tcp seq.html. That one should actually work.

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

  8. 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."
  9. Re:For those wondering how insecure Microsoft is . by fyonn · · Score: 2, Informative

    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.

    well, to be honest, it's not the most uptodate thing in the world. the freebsd tested was 4.2. and there have been significant improvements in tcp sequencing since then (being as we're at 4.6 now) and there is even a kernel compilation flag for random sequences.

    so it's probably a year out of date, don't feel so singled out

    dave

  10. 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
  11. 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
  12. Re:These pictures look familiar. by cvore · · Score: 2, Informative

    Your question is mostly answered on a realy cool article about chaos theory linked on the site, on the reference section :-) One finds simelar probability graphs on most new scientific stuff now: physiscs, chemestry and so on :)

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

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

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

  16. grsecurity patches by jooniqzb1tch · · Score: 2, Informative

    if you're interested in random ISN's I'd suggest you try the grsecurity patch from grsecurity.

    it has loads of other interesting functions and the random ISN generator seems to work fine, here's a nmap scan result :

    TCP Sequence Prediction: Class=random positive increments
    Difficulty=4184073 (Good luck!)
    TCP ISN Seq. Numbers: BA77562B B9B190FD BA8C8609 BA3DFEB2 BA92DBDB B9BA515C
    IPID Sequence Generation: Randomized

  17. 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
  18. CERT Advisory on this subject by Anonymous Coward · · Score: 1, Informative

    See http://www.cert.org/advisories/CA-2001-09.html. Also http://www.kb.cert.org/vuls/id/498440. It has some good background about why this was news at the time. For example, assertions in this thread that ISN prediction doesn't matter if you don't use address-based authentication are just plain wrong, and the advisory tells you why.