Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security

TCP/IP Sequence Number Analysis 229

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."
This discussion has been archived. No new comments can be posted.

TCP/IP Sequence Number Analysis

Comments Filter:
  • Must be Sunday (Score:2, Informative)

    by Anonymous Coward
    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.
  • old news (Score:1, Informative)

    by Anonymous Coward
    wasn't this already posted here like a year ago?
  • Keep in mind it's still remarkably hard to spoof with each successive packet, even if you can predict sequence numbers.

    The first is easy, the second likey, the third less likely, and so on. Spoofing a long conversation would be very difficult, if not practically impossible.

    • Re:Hmm. (Score:3, Insightful)

      by GigsVT ( 208848 )
      echo r00t::0:0:0wned:/root:/bin/bash fits in one packet.

      Food for thought.
    • Keep in mind it's still remarkably hard to spoof with each successive packet, even if you can predict sequence numbers.

      No. You are completely and totally wrong. The only hard part is predicting the initial sequence number. For each successive packet, the only problem is guessing how much data was sent so that you can ack it and not end up closing the window. In practice, this is easy, as the amount of data that was sent should be predictable within a narrow range, and it is safe to send multiple guesses.

  • Windows NT4 SP3
    Attack feasibility: 97.00%

    Operating system: Windows 98 SE
    Attack feasibility: 100.00%

    Operating system: Windows 95
    Attack feasibility: 100.00%
    • Comment removed (Score:5, Insightful)

      by account_deleted ( 4530225 ) on Sunday June 30, 2002 @10:13AM (#3795554)
      Comment removed based on user account deletion
      • 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
      • He didn't say insecure, but just that win98 makes a pretty graph...

        And it does, really! (Although I think Cisco IOS 12.0 makes an even prettyer one).

        Relax Bill, we're not out to get you....
      • by FreeUser ( 11483 ) on Sunday June 30, 2002 @10:55AM (#3795737)
        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.
        • 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%.
          Put that interesting tidbit together with Cringely's thoughts [pbs.org] on Microsoft's "TCP/MS" strategy with Palladium.

          I'm not usually a paranoid "MS wants to rule the world type" but this is a little too convenient a coincidence to ignore.
      • 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.

        So your saying when they ganked the FreeBSD network stack w/o even a tip of the hat, they improved thier non-existant security?

        Wow, who'da thunk.

      • Actually this is a case of "You Get What You Don't Pay For" -

        HPUX, Windows and AIX are all expensive and suck.

        Linux, OpenBSD, FreeBSD are all free and work wonderfully.

        So in this case, your level of protection is determined by your inteligence and not by the amount of money you sepend.

    • That's strange (Score:2, Insightful)

      by gazbo ( 517111 )
      When I read it they appear to have published the results to more recent Windows versions as well. You know, the more up to date NT versions, and 2k.

      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.

      • This could be because the linked report is dated "19 March - 21 April, 2001". This is not news, it's olds.
      • by FreeUser ( 11483 ) on Sunday June 30, 2002 @11:55AM (#3795990)
        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.
    • Yeah.
      Only a use of this attack is to get around IP filters, or to hide the origin of a communication.
      And you can't receive data.

      So attack is feasible.. but not that useful.
  • mirror (Score:2, Informative)

    by iamroot ( 319400 )
    Ok, I've mirrored the HTML and most of the images(still downloading) HERE [luminousdata.com]. Please only download this to mirror it! My bandwidth is limited!
  • by ahaning ( 108463 ) on Sunday June 30, 2002 @10:15AM (#3795565) Homepage Journal
    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.

  • This is the first section:

    Table of Contents:


    0. Abstract
    1. Introduction
    1.1 TCP Sequence generation and PRNGs
    1.2 Spoofing Sets
    2. Phase Space Analysis, Attractors and ISN Guessing
    2.1 Introduction to Phase Space Analysis
    2.2 Using Attractors for Spoofing Set Construction
    2.3 Real-Life Attack Algorithms
    3. Review of Operating Systems
    3.1 Linux
    3.2 Windows
    3.3 Cisco IOS
    3.4 AIX
    3.5 FreeBSD and NetBSD
    3.6 OpenBSD
    3.7 HP/UX
    3.8 Solaris
    3.9 BSDI
    3.10 IRIX
    3.11 MacOS
    3.12 Multiple Network Devices
    3.13 Other PRNG issues
    4. Risk Analysis
    5. Conclusions
    6. References
    7. Credits


    Appendix A: Phase Space Images of Known Generating Functions

    Hopefully now only people who want to read it will click on the link!
    • Funny I agree,

      This is propellor head stuff, but it is not overly technical.

      This guy is basically plotting pseudo random number sequences so that a human could look for patterns. Computers can not be trusted to find patterns in all circumstances, whereas a visual pattern can easily stand out to human eyes. Of course, there would be patterns that a human could not detect that would require a computer to find (witness MP3). The question is, how do you plot 32bit numbers which pretty much represent 1 dimensional data of very wide proportions between low and high values?

      Break the 32bit numbers up into smaller parts to be viewed as points in 3D space!

      I have been interested in LFSR (Linear Feedback Shift Register) PRNG's for a few years, starting out designing them in hardware and then finding out through reading Bruce Schneiers "Applied Cryptography", that I was actually onto something.

      I wanted to view my streams broken up into 2D dots as postscript to find patterns that showed weak (and thus the possibly strong) LFSR designs in the hope that I may find some high quality designs that have astronomical stream lengths before repetition.

      Though I wonder if 2D would be as good as 3D for finding patterns. It seems being able to rotate the sampled data in real time would be better for finding a pattern that can be missed with a single 2D picture. Or is this the authors way to simply represent very high resolution numbers on relatively low resolution screens?

      I have also been thinking of plotting streams to 2D images which I would then blur to greyscale to search for patches of light and dark to show low quality designs and save designs that show the best uniform shade of grey as possible candidates to be considered strong and thus used in designs that make up multiple hashed LFSR designs that provide stream lengths greater than the bit depth of the output itself.

      It's not technical if you are really into it. ; )

  • Not a new problem (Score:3, Interesting)

    by scotfl ( 312954 ) <scotfl@gmail.com> on Sunday June 30, 2002 @10:26AM (#3795618) Homepage Journal
    The idea of predicting Initial Sequence Numbers isn't exactly new, RFC1948: Defending Against Sequence Number Attacks [rfc.net] was issued in 1996. Heck, even RFC793: Transmission Control Protocol [rfc.net] 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.

    • The solution proposed in RFC1948 is to bias the sequence number by a hash of a secret value and the source IP address and port numbers.

      This means that even if the underlying random number generator is very poor or not random at all an attacker will not be able to guess your sequence numbers for spoofing attacks. You will still be able to easily guess *your own* ISNs for subsequent connections so the system will appear to be vulnerable in tests like the one in this article. Some of the systems with poor 'attack feasibility' ratings in the article may in fact implement this mechanism.
      • Some of the systems with poor 'attack feasibility' ratings in the article may in fact implement this mechanism.

        Ehmm. No. They found exactly that in Solaris, and reported the issue.

        Roger.
  • it was here [slashdot.org].
  • More recent results? (Score:3, Interesting)

    by Westacular ( 118145 ) on Sunday June 30, 2002 @10:46AM (#3795685)
    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.
    • This report was published over a year ago, examining vulnerabilities that have been well-understood for >6 years. How is this news?

      For me, although the problem is very old, anyone without a good understanding of statistical analysis won't understand why some semi-random ISN generators are better than other semi-random ISN generators.

      By applying this particular visualization scheme, they help to make it clearer. If you're lucky enough to find one of the mirrors where the images are visible, the difference between Linux 2.2 and IRIX is phenomenal. The "nodes" (areas of high spot density) on the IRIX plot clearly show places where guessing ISNs will be more productive. The Linux 2.2 plot just looks like a big fuzzy cloud, slightly more dense in the center. Some of the other plots show interesting patterns like dense squares-within-a-cloud or a small number of very dense nodes.

      Possibly the most interesting part, however, is how something like Cisco IOS looks kind of like Windows 98. They "look" similar even though the statistics given (attack feasibility, etc.) are vastly different.

      I think the news is in the visualization methods, not in the problem or the solution. As you noted, those are nothing new.
    • Unfortunately, even though this paper is somewhat old, many of the operating systems mentioned in it are still running and connected to the Internet.

      Besides, if the engineers at some company (SGI, MS, IBM) didn't previous think ISN prediction was a problem a couple years ago, they it is not likely they think it is a problem today.

  • The BSD's (Score:3, Insightful)

    by Foxman98 ( 37487 ) on Sunday June 30, 2002 @10:47AM (#3795693) Homepage
    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.
    • "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.
  • Hit them. Hard. (Score:1, Flamebait)

    by Krapangor ( 533950 )
    An attractor is a shape that is specific to the given PRNG function, and reveals the complex nature of dependencies between subsequent results generated by the implementation.

    The author should be hit with a stick.
    Hard.
    Several times.
    There is a standard definition for an attractor in mathematics.
    If the author wants to use mathematics, then he should use the well-agreed mathematical definitions and not vague pseudo-mathematical babble.
    And yes, I am a mathematician.

    What they basically do is to guess the (internal) dimension of the system and trying to get non-trivial attracting set out of it. It's a rather trivial fact that if you get both things right, you can attack the PRNG. However, a decent PRNG won't have any non-trivial attractors.

    • Re:Hit them. Hard. (Score:3, Insightful)

      by 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.
      • Even if you're presenting stuff to specialists, you need to be a little more vague and pseudomathematical for people to understand.
        The problem with always using "well-agreed mathematical definitions" is that not everybody understands them.
        And not everybody agrees as to exactly what those "well-agreed" mathematical definitions should be. They do tend to get pretty well sorted out over time, but it does take time and effort.
        Continuity is usually defined in terms of epsilons and deltas, valid enough in metric spaces, but the concept itself is valid for non-metrizable spaces which do not have distance functions. Is point-set topology a prerequisite for freshman calculus?
        Is measure theory a prerequisite for statistics? Ever wanted to work with both discrete and continuous statistics at the same time?
    • I'm a proud owner of a Mensa membership card.

      That may be, but I'm the proud owner of a brain, and my brain can out-think your card any day.

  • The article is not trying to report the idea of predicting the ISN as a new vulnerability.

    The goal of the article is to compare how vulnerable various current operating systems are to this type of spoofed ISN attack. It discusses phase space analysis as a worthy means of doing this, and then the article presents handy feasibility charts and pretty pictures.

    So please, let's have no more posts discussing how this attack is really old, man. I think most people here know this already.
  • by Anonymous Coward
    1. Sensationalism
    "OMG Someone can guess the ISN number, We are all on our way to destruction"

    2. Geekiness
    "Wtf is an ISN number"

    3. M$ Bashing (Note the $ $ign it means I dissaprove of Microsofts Money Grubbing Ways (TM) [OMG another funny!!])
  • ... at http://www.mirrors.wiretapped.net/security/info/pa pers/networking/strange-attractors-and-tcpip-seque nce-number-analysis.pdf

    hardcode

    --

    It's 106 light-years to Chicago, we've got a full chamber of anti-matter,
    a half a pack of cigarettes, it's dark, and we're wearing visors. Engage.
    - Paul Tomblin in asr
  • So, in Neon Genesis Evangelion, when they discover the Eva "neutralizing the Phase Space", they are actually watching the Eva exploit the Angel's weak ISN via a TCP/IP connection? It all makes so much sense now.

    They manage to build bio-humanoid robots, but they can't write a decent random function. Go figure...
  • Time delay... (Score:2, Informative)

    by MConlon ( 246624 )
    Normally when you're attempting to reconstruct phase space you vary the embedding dimension.

    Just because the dynamics look like a cloudy haze in R3 doesn't mean they do in R8.

    MJC
  • by Tusaki ( 252769 ) on Sunday June 30, 2002 @11:48AM (#3795969)
    I mean, really!
  • Predictable ISNs are only a problem against a machine which has been configured to allow another machine privileges based solely on that second's machine IP address. Then pedictable ISNs allow a third machine to 'spoof' it's address, claiming to be the seond machine by using it's IP address, even though the third machine can't see the responses from the first machine, because the third machine doesn't have the IP address it's claiming.

    If you don't configure this 'trust' relationship based on IP address alone, this is not an issue.

    Example: SSH allows one machine to trust another, but requires that the trusted machine be at the right IP addresss AND posess the correct private key or keys - so no issue.

    Any one who, in this time, configures a machine to trust another, based solely on the IP address in the frames received, is crazy. It's a very unwise practice.
    • Uh.. DNS

      Let's say the next time you load up thinkgeek.com and buy some overpriced gadget, your machine gets a spoofed ip during the DNS query, and instead of talking to thinkgeek.com you pass through some web proxy that harvests your credit card number and personal info (perhaps you fail to notice the lack of https:// this time). Of course, your thinkgeek order proxies right through to thinkgeek.com properly by the spoofed machine, then your local DNS cache expires and there's no trace of what happened.
      • Uh..DNS *queries* are UDP. Only TCP has this 'issue'.

        And if you order something online w/o verifying HTTPS, you're a moron. Plain and simple. If you *were* DNS spoofed, hopefully your browser would issue a warning that the Cert was invalid.

        DNS has its problems, yes...But they have nothing to do with ISNs.
    • I think predicting ISNs also lets you hijack a connection...

      You let Alice telnet into Bob's machine and do enough that she's had time to enter her password. You then DoS Alice into next week while sending telnet packets to Bob that will create some sort of hole for you to come through later.

      Bob sends the responses to Alice but she doesn't see them because she's flooded off the net, and Bob doesn't bother resending them because you ACK the packets.

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

      Configuring a machine to trust another based soley on the IP is actually rhosts, I think. I've never actually used it, but that sounds right. And yes, it's supposed to be quite insecure.
      • I think predicting ISNs also lets you hijack a connection...

        I think this is far more dificult than if a machine is using rhosts. You need to know that the user is looged in. You need to guess the ISN, then guess how many other bytes haved floed to get the current SN. Seems much more dificult to me.

        Now SSH does prevent this, ... but you can't fake the encryption without knowing the password (and if you knew that, you'd just log in normally.)

        Actually, the encryption is not based on the password. IANAE, (I Am Not An Expert), but I think SSH uses a public key exchange to encrypt an exchange where a session key is selected, the session key is then used in symmetric encryption. So you'd need the user's private key, AND to be able to see the traffic from the target back to the user (which is encrypted using the user's public key) at least to hijack the session. Since we're talking ISN predictability issues here, this is usually an issue when you can't see the traffic from the target - otherwise, you'd know the ISN and predictability would not be an issue.

      • Re:OLD AND SILLY (Score:3, Informative)

        by stripes ( 3681 )
        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...

    • Predictable ISNs are only a problem against a machine which has been configured to allow another machine privileges based solely on that second's machine IP address.

      Are you willing to bet that this is the *only* kind of attack possible using sequence number prediction? Someone with a sick imagination may find other novel and destructive uses for it.

      In fact, I can already think of some...
  • Stup[id plug. (Score:3, Informative)

    by mindstrm ( 20013 ) on Sunday June 30, 2002 @04:43PM (#3796947)
    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.
  • 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.
  • if you're interested in random ISN's I'd suggest you try the grsecurity patch from grsecurity [grsecurity.org].

    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
  • That is the most interesting thing i have seen on Slashdot for a long time.

Know Thy User.

Working...