Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
News

TCP Weakness No False Alarm? 144

Posted by timothy from the pooh-pooh-or-poo-poo? dept.
An Anonymous Coward, indicating this ZDnet story, writes: "Apparently e-week had to eat it's words. The Newsh (Tim Newsham) is well respected in the security community, and his work has been confirmed by many sources as being a major problem in the implementation of TCP on many operating systems."
This discussion has been archived. No new comments can be posted.

TCP Weakness No False Alarm? More

TCP Weakness No False Alarm?

Comments Filter:

  • Re:Still short on details (Score:1)

    by Anonymous Coward
    Each packet has a sequence number, and an ACK number, which is the sequence number it is expecting from the other end of the connection. It is a two way stream, so two numbers are needed. So each machine has its own ISN for each connection.

  • A Long Time Ago.... (Score:1)

    by Anonymous Coward
    ...this was discovered, well, perhaps not discovered by first made popular and public by Kevin Mitnick.

    Kevin used TCP ISN prediction on machines with "rsh" enabled to hack into computers on the net.

    For a detailed explination, check out Network Intrusion Detection: An Anlysist's Handbook, good reading.

  • Rant (Score:1)

    by Anonymous Coward
    Make it so, Malda. Let these little punks post their crap. When they get no attention they'll eventually move on.

    Does Malda want them to move on? The trolls add page views by the buttload. So does Jon Katz who seems to attract 90% flammage. Broken moderation that encourages kharma-whoring just adds to the frenzy, not the discussion.

    Why do most stories *die* (from a moderation/discussion point of view) within 12 hours? Partly because the noise is so high that a discussion becomes more difficult but further all the kharma hunters increase noise.

    Then they bitch about losing kharma. Not because one post got marked down, but because the loss of kharma affects the ranking of other posts.

    Malda and friends could make a system whereby trolls would have little to troll about. All posts could stand on their own at the same default rating (1). Rather than meta-moderation, just have the moderators name posted next to their markup/down.

    Why is moderating anonymously an act of courage but posting anonymously an act of cowardice? Perhaps it was a cute label at first, but the "Coward" bit remains to encourage flammage and to goad people into REGITERING.

    Who benefits from registration? Slashdot does. Registered users - in the internet "economy" - are considered gold. Especially to marketers. Who benefits from having a direct linkage to their insane ramblings? Why would I want to link my comments to an ID only to see them in a civil suit, trademark/IP case, or divorce hearing? What benefit to me is it if I have no website or public persona to promote?

    Slash/Malda loves the trolls. Trolls == Money. They love registered users. Registered Users == Money. Now, I don't blame this after all: I LOVE MONEY TOO. But does it make Slash a better place? No. Does it make me want to contribute to their well-being no? Will it stop me from blocking their adds (ooops no money)? No. Will I smile if it goes, in the words of the Register, titsup.com? Yes. Yes, indeed.

    BATTLE ON XENA

  • Re:Still short on details (sic!) (Score:1)

    by Anonymous Coward
    The ISN isn't created by two computers, just one.

    There are two ISNs, one for the side requesting the connection and one for the other side accepting the connection. Both ISNs are independent of each other. Two ISNs are necessary necause TCP is full duplex with both directions being independent: you can close one direction and still keep the other. Just read Andrew Tanenbaum's "Computer Networks". But please, read!

    For hijacking a connection to a server, the sequence numbers of the client are important, because a hijacker needs to generate them. For this he either needs to eavesdrop one client sequence number or better, if he can guess it he can right go away without the need for eavesdropping at all (blind spoofing).

  • This is not new at all.... (Score:1)

    by Anonymous Coward
    No way is this new. Even this guy's new "spin" on it was covered in "Maximum Linux Security". In fact in that book, there are pointers to code that will automate this procedure and make attempts at guessing sequence numbers. In fact even "nmap" has an option (-O) that will tell you how easy it will be to infer a given target's sequence numbers. This is nothing but someone using fear-mogering to get some press.
  • Billy Gates wrote:
    I am no cs major...

    Thanks, Mr Gates, but we knew that all along ;-)

    About the MAC addresses: these are just serial numbers put into the card's EPROM, and are very easy to spoof, especially if you put them into the payload of the Ethernet packet rather than the header. And even for the header (only present on the local LAN), they can be set at will by most cards. You see, most cards have two MAC addresses: the "hardware" MAC address, set at the factory, and not modifiable, and a "software" MAC address, stored in RAM and thus modifiable at will. The software MAC address is used for packet headers. The hardware address is only used to initialize the software address after a reboot; however, there is nothing that stops an ill-intentioned user to do an ifconfig eth0 hw ether 42:69:6c:6c:20:46 and change his MAC to "Bill G".

    For communications beyond the local LAN, the point becomes even more moot, as the Ethernet header is not transmitted. Thus any MAC address present in the packet would need to be in the payload of the packet, rather than the header. And in the payload, it is trivially under control of the OS, and hence the attacker.

  • summary of the problem (Score:3)

    by Anonymous Coward on Thursday March 15, 2001 @06:19PM (#360303)
    A reasonable summary is available at http://www.kb.cert.org/vuls/id/498440
  • Anyway, my only point with telnet was that I thought it was already commonly accepted that encryption was the only thing that was going to stop hijacking. I guess this may get proved out.

    The reason for using SSH is not only to prevent password sniffing, but to also make hijacked connections useless. So someone can still take over or interrupt your connection, but it's pretty useless for the attacker when all content is encrypted.

  • The "OSI Model" is just that, a model. (there is no such thing as "OSI protocols")


    Really.. then whats the in the last column of your link [lex-con.com]?

  • Re:What do you all think about using mac's? (Score:3)

    by Joe Rumsey ( 2194 ) on Thursday March 15, 2001 @10:40PM (#360306)
    There's at least one legitimate reason to have reprogrammable mac addresses. At the last place I lived, I had a cable modem that was set to work only when connected to a card with a specific mac address. Any other mac address and it wouldn't work at all. I could call the cable company to change it (and when I moved, it appeared they were working on letting you do it via a web page), but having a programmable card would have been less annoying. Yes, it was braindead, but what are you going to do when your other choices are pricey, slow DSL or a plain old modem? That's right, deal with it.

    I now have a little SMC router that will let me reprogram its Mac address, it would've been good at that place, but I don't need that feature any more, thankfully.
    • If the government had control over the internet, it would be quite a censored, wiretapped shithole, instead of the neutral ground that it is today.
    Um, for most of the Internet's existence, it has been under government control. It was considerably cooler in many ways before it was privatized.
    • I *certianly* don't think it will be destroyed... not today, not tomorrow, not ever.
    Yeah, we used to laugh at the people who predicted the death of USENET.

    And then it died.

  • Uhhh ok so what protocol do you seggest the entire internet use instead then? and when can you start migrating everything to this new "better than sucky old IP" protocol?

    Well delta-t seemed pretty cool, and it isn't all that complex if you drop the parts designed to handle non-8-bit-bytes and assume NTP will be used to sync time. It was one of the proposals that TCP bested last time around. Delta-t also has the cool property that it can find the right rate to minimize loss on non-garenteed connections (so you could get something like UDP with TCPs auto dampening properties). Regretabally I think that only works of symertrical links (so satalite forward link with dial-back won't work, and ADSL might be a problem as well, but I think not).

    As for deployment, well it'll face the same problems IPv6 has. It'll be better, but not enough better to get anywhere real fast. Of corse it may not actually even be better, I never saw an implmentation, and it hasn't had the decades of tweeking TCP has (things like delayed ACK, and nagel, and some of the recovery algos).

  • Re:Similar to telnet hijacking? (Score:3)

    by stripes ( 3681 ) on Friday March 16, 2001 @04:42AM (#360309) Homepage Journal
    To say initial ISN is redundant; to talk about subsequent ISNs is wrong, as there are no such things.

    The initial ISN is the first ISN a TCP stack uses after it boots. The subsequent ISNs are ones it makes for the second and subsequent TCP connections.

    If the first ISN is chosen totally at random, but the rest of the ISNs are chisen by adding three to the old ones, or even by calling bad_PRNG()&0x07, then you are screwed after a few connections...

    One of the wrinkles is you can't just do "ISN = good_PRNG()" because you have to avoid reusing ISNs within some time limit (I think it is something like four times the maximum segment lifetime, but it could be longer).

    The easy approach is to pick as random an ISN as you can the first time, and then just add a random number the other times. However if the random addition is too large you can wrap the ISN space too quickly and reuse ISNs before the 4*MSL timer expires. If the random addition is too small even a good PRNG (or a real RNG!) is operating in too small a space to be safe.

    One could have two 64Kbit (~8K byte) arrays ISNcur, and ISNprev, make a random ISN (using the best PRNG, or a RRNG) and if it's bit is set in either array make a new one, if the bit is clear set it's bit in ISNcur. Every 4*MSL copy ISNcur to ISNprev, and clear ISNcur (which you could do by moving pointers, and clearing one array, but it still sucks to screw with 8K of data, not good for the cache).

    Or one could just come up with a decent distance for ISNs, gennerate the random number in that space, and live with the possibility of wraps, and the somewhat reduced "keyspace". Seems a lot easier and faster :-)

  • A friend of mine and I have developed a patch for the Linux 2.4 kernel that can, amongst other interesting things, rewrite the ISN of connexions to routed machines. In particular, it can generate truly random ISNs. A release for the 2.4.2 kernel should be available soon on the project's website :
    http://ippersonality.sourceforge.net/
  • Hijacking the TCP connection underlying an SSH session doesn't allow you to do anything interesting with the session because you don't know the secret key that's being used. All you can usefully do is disrupt the session.
  • People may not use .rhosts, but they may still use IP addresses in tcp.allow/deny, Apache's access.conf, etc. I know I've done this - but it was backed up by a firewall configuration that prevented external spoofing, and I already trusted the other network users enough to be sharing a house with them.
  • What really pisses me off about this is that there is not a single bit of information on what is vulnerable... Guardent claims they 'wanted to make the public aware of the problem while working with vendors', but what other information than 'Guardent is great' has been released?

    I still don't know which of my systems are vulnerable and which I can securely leave on the net assured that noone is misusing them as a DDoS tool [securityfocus.com] without me being able to do something about it (and no, you can't require IPSEC for people connecting to a web server).

    If Guardent doesn't release the details, they could at least tell us what systems are affected before touting this as a 'major problem'.


    --

  • This whole thing was brought up about two years ago. Microsoft Never saw the need to randomize the ISN's or the Port usages. That is, I beleave against the spec these days. Linux I belave has a fully to the spec TCP/IP Stack. The thing is, this is all VERY old news.

    In response to Win98, It does not use an ip as an authenticator, Windows in general does not use an ip as an authenticator, but it does use Machine Accounts in NT, oh this is from X machine, oh ok, Its good. Win98's only service is really File and printer sharing. In win9x, its basiclly the same as samba set to SHARE instead of USER. People sharing their c:\ is what all those vbs worms are hunting for......
  • This whole thing is not even funny at all, We have known for ages that Windows did not create Random port numbers or Random ISNs, So why fret about it now?
  • OS/2 has GUI support for overriding the default MAC address on most Ethernet card drivers :-)

    This is a function controlled by the NDIS drivers, but almost of all the OS/2 NDIS drivers have it.

    Anyone using the MAC address for authentication is at risk.
  • *ATTENTION*

    In case there was EVER any question on whether the moderators get the best crack, this should settle it.

    This +5 post (!) is nothing more than a person biting (hard) for a troll. It's gullibility, not insight. To be fair to Mox-Dragon, it was a very good troll.

    People, read the frickin posts. Look at what he replied to! Hell, he pasted it inside his own comments! To get the full flavor of it, look at the root of this thread. It'll make you laugh.

    And give qtp some karma so his efforts will have more effect in the future :-)

    --

  • I can break into your car, your house, tap your phone, look through your trash to get info about you. I can kill you in your sleep.

    Granted.

    Just because I can doesn't mean I will though, just as most people woudn't.

    Here's where the trouble begins. I grew up in a small town in Michigan. When I lived there, the chances of malicious activity randomly directed at me were staggeringly low. Now I live in Chicago, and it's much MUCH bigger. And the chances of malicious activity affecting me are much higher, but still pretty low.

    But when I'm on the Internet, it is to Chicago what Chicago is to my hometown, only more so. You see what I'm getting at? When I'm online, or rather, when my box is connected (24/7), it is accessible from anyone else in the world who's on the Internet. And it is accessible in seconds. Now, I have no doubt that there are miscreants in my neighborhood here in Chicago, but they're on the order of magnitude of about a few hundred, and it will take them a lot longer than a few seconds to lay any kind of attack. When you take those numbers, and increase the number of thugs and decrease the time it will take them to get you, then you need to take precautions, regardless of how unlikely it is for any given individual to attack you.
  • Personally, I feel a lot more comfortable every time a vulnerability is discovered and disclosed. The alternatives are, in no particular order:

    1) no one finds it EVER (unlikely)
    2) it gets silently fixed (if you fixed your code, I bet you would tell your users)
    3) some misdirected yet highly talented kid discovers it and exploits it.

    Or, you could just go on leading your blissful carefree computing life while your box remains a haven for the people who keep bumping into my firewall.
  • > With Mac OS, you have a 100% probability of guessing the correct number (unless you are a fucking idiot. ;-)

    Strangely enough, nmap return this when run against my mac.
    It does not look so easy to spoof.

    TCP Sequence Prediction:
    Class=random positive increments
    Difficulty=60740 (Worthy challenge)

    Sequence numbers: 1C4ABBC3 1C4CAFD8 1C4F99ED 1C518A02 1C55E217 1C57EE2C
    Remote operating system guess: HP-UX B.11.00

  • This sounds an awful lot like he's saying that, given the information you can sniff over the net, you can predict the next number the PRNG used by the TCP stack will produce. I'm pretty sure that's true, if the stack's using a poor PRNG, and the only fix is to use a better PRNG. I don't see how his fixes affect this, though. Crypto algorithms that are worth anything basically attempt to produce an output string that is indistinguishable from random numbers if you don't have the key, which is the same goal that a good PRNG tries for. So exactly how does his fix differ from switching to a better PRNG? And how can it help systems that already have good PRNGs in them? As for adding in an administrative passphrase, sorry but that's likely to reduce the randomness thanks to the penchant of humans to pick memorable ( and thus non-random ) phrases.

  • I believe its controlled in the nic's firmware and can't be overidden.

    That would be a bad asumption. There are at least a few systems on which the MAC address can be overridden, including older 32 bit SparcStations at least, where it is stored in an NVRAM that is programmable. Also, on many NIC cards for PC's the MAC address is stored on a PROM which is socketed, and can therefore easily be substituted. Even for those where it is not socketed, it is far from impossible to unsolder and replace the PROM.

    A cracker can't make a fake mac wihout his or her own mac address bing automatically sent out.

    And that doesn't guarantee much safety given the current price of NICs, a cracker can buy 'throwaway' NICs that he/she uses for only one attack and then disposes of. This approach doesn't allow a cracker to assume someone else's MAC address, but it makes tracking them by a MAC address much more difficult.

    What if we modify the tcp/ip stack so it can read mac's and automtically send macs?

    That probably won't help much, because you won't be able to trust that nobody has altered the TCP/IP stack code to send fake values. Even in a closed source OS, it wouldn't be impossible for someone to disassemble and patch the code.

  • Perhaps what we need is a list of the poor implementations. I doubt FreeBSD, Linux, and OpenBSD will be in there. But which ones will? And are there any E-commerce sites worth 0wning running on them?

  • Clearly, rsh needs to not only be disabled, it should even be included anymore. If someone needs it desperately enough, they either run an old system or download the source and do you know what with it.

    THE biggest source of insecure systems its the numbskullery of the system vendors that make things this way. And most of that is NOT from the rank-and-file techies at the bottom of the rung that know better. It's on the part of the management who think as long as they hide the source code, know one will know that they haven't allowed any real upgrades for security, all because it might inconvenience some customer who would have to reconfigure something to operate in a more secure environment.

  • I don't know, that doesn't sound very authentic. The previous times that the Internet has been down for maintenance, it has been on New Years Eve, and I was warned about what could happen if I left my computer plugged in.

    Either you're just having us on, or you're an incredible bastard by not informing the new users that their hard drive could be erased, their CPU destroyed and their PC set afire.

    --
  • So they seem to say the problem is not that the initial ISN isn't created randomly, it's that the subsequent numbers aren't incremeted randomly (wouldn't that be hard to do?) but are rather incremented by the number of bytes transmitted.
    The ISN is the Initial Sequence Number. To say initial ISN is redundant; to talk about subsequent ISNs is wrong, as there are no such things. The bit you quote most definitely is saying that the ISN isn't getting chosen randomly.

    Incrementing the sequence number randomly between packets is impossible. The purpose of the sequence number is to allow one machine to know if it failed to receive any packets. If one machine gets packets 1, 2, 3, 4, 6, and 7, it knows that packet 5 got lost. If the sequence numbers were random, how could you know if one was missing?

  • Re:Still short on details (Score:3)

    by tap ( 18562 ) on Thursday March 15, 2001 @06:04PM (#360327) Homepage
    The ISN isn't created by two computers, just one. So the information used to create it doesn't go over the network. If you had a real random number generator, then guessing the ISN would be next to impossible without intercepting the traffic en-route to the real destination. But lacking that without special hardware, you have to settle for pseudorandom numbers. Some pseudorandom number generators have weaknesses that can be exploited.

  • Re:Details (Score:5)

    by tap ( 18562 ) on Thursday March 15, 2001 @06:57PM (#360328) Homepage
    For each sequential packet, a new ISN is generated

    While your post was very informative, this part isn't quite correct. The ISN is the Initial sequence number. The server generates it when it sends back the syn/ack packet to the client. The sequence number of subsequent packets is the ISN + the number of bytes transmitted so far.

    So if the syn/ack packet had the pseudo-random sequence number 1042, and the next packet from the server contained the data "HELLO", its sequence number would be 1047.

    It's worth pointing out that there are two seperate sequence numbers, the one generated by the server, and the one generated by the client. The client ISN is sent to the server in the SYN packet. It isn't a problem for spoofing, because the spoofer is the one generating it, so obviously they know what it is.

  • Reading the article (yes, some people actually do that now and then) it looks like the problem isn't with the PRNG, but rather with the idea of random increments. Most of this is conjecture, so take with a grain of salt, but it seems to fit a lot better than most comments here. The problem is that the ISN for each connection is the ISN for the last connection plus some random increment. Even if that increment is truly random, as long as its largest value isn't too large we can easily 1) establish one connection with the host 2) wait for the target connection we want to take over 3) establish a new connection. Now we have a reasonably small range of ISNs (between those of our first and second connection) to try. Even if each of those increments were truly random and we have no basis for prefering one to another, we've reduced the space of all possible ISNs to a much smaller space. The only solution is not to use a random increment, but to use an entirely random ISN in the first place.
  • I faced a similar problem of generating non-repeating random numbers in a project at work. Where can I find more info about this algorithm of using modular division?

    thanks!
  • As for MAC addresses (Your ethernet card's hardware address for you newbies) is 6 byte (48 bit) unique address assigned to each network card. most can be changed nowadays. I believe 802.3 specifies a 2 byte address is valid as well, but I can't actually recall ever seeing one.

    The reason we don't use these addresses on the internet is partially due to address space, and partially due to the emergence of ethernet over the years.

    - When tcp/ip v4 was on the way, there were a lot of serial connections, and a lot less ethernet connections. Serial ports don't have mac addresses.
    - Mac addresses are 48 bits, and contain no routing information. Ethernet addresses are usually (in the case of those /24 or commonly called class 'c' networks even though they technically caren't...), 24 bits of routing information, and 8 bits of host information. No room for 48 bits of mac address.

    IPv6 has enough space to allow the automatic use of the mac address for the lower 48 bits of the local address, to make numbering simpler.. but still.

    And to end that... this all really has nothing to do with security. If you're using ethernet, it's not secure, you can fake your mac address.

    Mac based security can be foolproof if you use proper switches, and restrict which mac can talk on which port, to which other ports, etc.... but that's a real pain to administer. And it certainly doesn't work over the internet at-large.
  • So the real answer is to have properly managed networks, that don't allow spoofed packets to leave, and network subnetting that follows security domains.

  • Re:The Dangers of Guessable ISN's (Score:3)

    by The Infamous TommyD ( 21616 ) on Friday March 16, 2001 @02:33AM (#360333)
    I do know a fair bit about this. Random _INCREMENTS_ are worthless you just need enough packets sent to cover the maximum increment. I believe random increments is what many Unices and NT use but they probably use the same next sequence number counter for all connections.

    The way linux does it is to use a random start point per 4 tuple and change it every 5 minutes. It then adds a time-based increment to this. It should be very difficult to blind spoof as you wouldn't be able to guess the starting point for some other 4tuple. (ipsrc, ipdest, tcpsrcport,tcpdstport)

    You're right I hadn't read this article, but it didn't release anything I didn't already know about the situation.

    BTW, I happen to be a 5th year phd student in network security and I've done a fair amount of work in vulnerability analysis. To those who think this is just about preventing spoofing at borders, no it's not. That still won't stop attacks from inside networks.

  • The Dangers of Guessable ISN's (Score:5)

    by The Infamous TommyD ( 21616 ) on Thursday March 15, 2001 @07:21PM (#360334)

    Ok, we have the usual batch of dumbass guesses on /. Most are wrong or only partially right.

    If you can eavesdrop on a TCP session, you can hijack it regardless of the randomness of the TCP ISN. This is because you SEE the ISN in the SYNACK returned by the server. This is a fundamental flaw in TCP and is left to upper level protocols to prevent. (like ssh) Telnet, ftp, etc. don't. It doesn't matter because this isn't really what the advisory is about!

    The real problems with guessable ISN's is when you can do something to a server like a probe to sample the sequence numbers and then make good guesses as to what the next one will be. Then you can do BLIND spoofing where you don't have to eavesdrop. The worst use of this is to exploit .rhosts and hosts.equiv type trust relationships. Basically, if you can blind spoof, and the packets can get to the end box that trusts a given IP address, you can execute commands on that box. This is a big deal. Also, if you can blind spoof, you can easily reset the connections being served by the server by sending TCP RSTs. This is a low bandwidth DoS that is quite devastating.

    The deal here is that everyone thought that they had "good enough" randomness for ISN's, but it looks like many implementations don't. The problem seems to be that the poor implementations are widespread.

  • I believe that would be called IPv6.
    --
  • I run IPSEC between my boxes over an E1 (2Mb/s circuit).

    You can really notice when they're trying to encrypt a full 2Mb/s of traffic. Mind you - they are only Pentium II machines.
  • This is still more complex than that... There is no fixed number "n" indicationg the number of packets to be sent without being acknowledged.
    During the three-way handshake, the client and the server (read: the machine which actively opens the connection, and the machine which agrees to this connection) both advertize the number of data they can immediately recieve, which is called the "window". A machine is allowed to send as many bytes of data as the window is tall, without waiting for an ACK.
    When an ACK is recieved by the sender, this means that the reciever acknowledged having successfully recieved all bytes, up to the one whose seq. number is the ACK number. The number of bytes ACKed will be suppressed from the sender's retransmission queue.
    The reciever, sending an ACK, will in the same packet advertise a new window to the sender, for more data to be sent.
    If data is not acknowledged into a given amount of time, the data still unacknowledged (on the retransmission queue), will be re-sent.

    Well, hope it helps...
  • Hermmmm... this "shared secret key", which have been established during the session negociation, is, by definition, secret, and only known by the two connected machines... So, how could an attacker inject data which makes sense in the stream (as data is interpreted as encrypted by the secret key), or decrypt anything exchanged (as data is, indeed, encrypted by the session key)?
    Just because the encryption uses a symetric algorithm during the connection, and no more an asymetric one like the one used in session negociation, does not make it more insecure!
  • So who said anything about sniffing?

  • Back in the really old days, DECnet would set the MAC address to a value simply derived from the DECnet address. If you couldn't set the MAC, you couldn't use DECnet.

  • Perhaps we should give control of our private lives over to the government too. We have obviously failed at our own morality. That is the real root of the problem when it comes to crime and terrorism. Perhaps the government should install cameras, so it can watch us, for our own good. Just until they fix our morality problem. Do you REALLY want the same people who pay $250.00 for a hammer to "take back" the internet and "fix" it? The same people that run the IRS? Another little fact to consider; Its the WORLD WIDE Web. Don't you think that other countries will be a little annoyed at our government's attempts to "fix" the internet? These kind of doom and gloom predictions serve NO purpose. Is the internet perfect? Heck no! Will it eventually shake out? Heck yes! Try to use your logic on the discoverers of fire. Did the fire burn a few people before they knew how to handle it? You bet. Did the fire go out a few times before they learned how to tend it? You bet. Did naysayers want to go back into government funded damp cold caves without fire becuase of all the difficulties? You bet! Gedvondur
  • From the artile:
    Bellovin added that in light of Newsham's discovery, the only reliable ways to guard the integrity of TCP sessions are cryptography or his fix, which involves basing the ISN on a complex combination of a random number generated by each machine, an administratively installed secret phrase and the machine's IP address.

    Isn't this basically what Linux is already doing right now? Except that the pass phrase is not installed manually by the administrator, but rather generated randomly every 5 minutes. At least that was what I understood from a couple of mailing list messages a few years back, when the problem was first considered, and from th function secure_tcp_sequence_number in /usr/src/linux/drivers/char/random.c.

  • LAVARAND [sgi.com]. The coolest random number generator on the web since 1996!

    It is always good seeing SGI at the forefront of technology:)


    Frog51
  • I believe you have no idea what you are talking about. I have a tunnel to the IPv6 backbone, and there is no crypto involved in the protocol.
    As far as I have seen, there is nothing in the protocol that would lead me to believe that IPv6 cannot be spoofed as well. In fact, a little bit ago, I heard someone was spoofing v6 over v4 tunnel traffic and injecting spoofed traffic into the 6bone.
    Please actually read something other than a hyped magazine article or editorial claiming IPv6 is the solution to everything, or it will make your food taste better, it won't. It is just another protocol with oodles more address space. In fact, to get technical, iirc, once IPv6 is fully deployed you will need at least twice the RAM in your router to carry the full routing table, if it gets to be the same mess the current v4 table is.
    -Paul Timmins
    3ffe:2900:1100::/48
  • Apple did a lot of work to the TCP/IP in OS 9 and the new Open Transport, such as disabling the ICMP ping reply, which would have mad it vulnerable to participating in a DOS attack.

  • Alright, then I'm gonna show my ignorance of TCP/IP fundamentals:
    If only one of two machines generates the ISN, how does the other one know what the ISN should be? Or is it just echoed back in the next packet, so if there is a disreptency the host that was supposed to generate the ISN can say "Whoa, buddy, I didn't send you that packet?"

  • The story seems to suggest that it is possible to garner enough info from eavesdropping to guess an ISN (sequence number), which are now pseudorandom on most network-worthy OSen. So it then does not matter if the next ISN is pseudorandom, pseudopseudorandom, or simple enough for GW Bush to guess. This seems logical to me, as all info that the two puters use to create the next ISN has to be something that a middleman would be able to capture, or the other end wouldn't be able to see it, right? Or am I missing something obvious here.

    Of course, it does point out the solution: end-to-end crypto. That's definitely something I'd like to see, though I suppose I'd need a faster puter for peak traffic times.

  • Also, most machines now allow you to change the apparent (and sometimes the actual) MAC address fairly easily. This is generally a Bad Thing, but makes it easy to spoof traffic authenticating by MAC address. What exactly is bad about chaning apparent MAC addresses (i can understand not wanting to change actual address) good uses for it: if you want redundancy at the nic level, it works best if both/all cards are using the same mac address, in case a card dies, a seemless changover can take place, without having to wait for arp things. if a nic decides suddenly that its mac address is actually 00:00:00:00:00:00 but works fine in all other respects (actually has happened to me), the cable company doesn't want to add that address to its configuration files, so its easier to tell the os (win98 in this case) to use the old address where it would be a bad thing would be where you were relying on it for authentication, but using something like that doesn't seem like a good form of authentication, because spoofage has always been possible, perhaps requiring reprogramming a prom of some sort if the software won't do it
  • sorry bout the formatting, wasn't logged in, and apparently ac defaults to html, where my account defaults to plain old text
  • The author of "Interconnections" (reviewed here earlier this year) mentions that IPX+ would have made a much better backbone to the Internet.

  • The WORLD has security flaws! and other randomness

    Oh the irony!!!

  • Yes, you've got the idea. They can hijack your connection and pretend to be you, but they're hijacking a connection of two machines sending seemingly random characters to each other.

    [TMB]
  • I wish you would run for political office. We need people who have good common sense in positions of power and responsibility.
  • Re SSL (and pardoning the lack of rigor in the following), the certificates are used only to authenticate the parties and establish a "shared secret key" for a session (which is then used to encrypt the actual communication). In other words, once you're connected the certificates aren't used anymore. So, if the snooper "listened in" while the session was being established they could get the "shared key" and hijack your connection.
  • Still not quite correct.

    The TCP sequence number is based on the first byte of data in a packet.

    This segment would have the same sequence number regardless of the number of bytes of data contained in the packet.

    the sequence number for future segments would be incremented, however.

  • It was pretty obvious that this guy *was* a troll... I just needed something to do.

  • Crypto (Score:3)

    by Mox-Dragon ( 87528 ) on Thursday March 15, 2001 @06:03PM (#360357)
    Old McDonald had a farm, EIEIO
    And on his farm he had a crypto, EIEIO
    With a cipher cipher here and a cipher cipher there
    Here a cipher, there a cipher, everywhere a cipher cipher
    Old McDonald had a farm, EIEIO

    Seriously though, Crypto is everywhere these days, and it's use proliferates more as internet use rises. The article mentions companies being reluctant to implement the fix because of computational intensity - that's silly, the only way you are going to secure *anything* is by using good crypto, and good crypto is inherently computationally intensive. It's also absurd to keep using an insecure method of doing anything beacuse the fix takes too much CPU time to implement - if what you are doing is insecure, STOP, before someone gets compromised, and fix it... of course, it's easy for me to say this, because i'm not in their situation.

  • Re:Surprise surprise. (Score:5)

    by Mox-Dragon ( 87528 ) on Thursday March 15, 2001 @06:14PM (#360358)
    Yes, the Internet is in a dire state of vulnerability, and nerd parroting "just update BIND" isn't going to help a thing. DDoS attacks against major web sites, stolen credit cards, hijacked identities - tech news reads like devil's brew of disaster. People need to wake up and face the hard truth.

    First off - don't be so sensationalistic. You're being as bad as the news that "reads like devil's brew" - everybody on the internet is NOT going to get broken into, everybody's identity isn't going to get stolen, and satan is not going to come to earth. The news sounds like a devil's brew of disaster because the news media only reports the bad things when it comes to security - "major corporation not hacked into" doesn't make very good headlines. Just because some holes pop up here and there doesn't mean we need to have the government pop in and take it all back - it just means we need to work on it a little.

    The private sector has failed. It was supposed to be a grand experiment in freedom, as academia and the business world allied apart from government control. It was supposed to be an electronic utopia. Instead, it a war zone rife with terrorism.

    Maybe in your mind. To me, the internet is both a place to be and a tool - nothing more, nothing less. I don't think anyone ever intended it to be an "electronic utopia" - and I certianly don't think it is a "war zone rife with terrorisim." The internet isn't a war zone until I'm afraid to log onto IRC or AIM for fear of some marauding bad guy getting my IP, finding out where I live, and murdering me in my sleep. And I think we're pretty far off from that.

    The governments of the world need to take the Internet back, at least until it can be secured. Desperate times demand desperate measures, and if the Internet doesn't give up freedom for a little while, it will be utterly destroyed.

    Bzzzzt. Wrong. First, I agree with Ben Franklin in that anyone who gives up freedom for a little temporary saftey deserves neither. Second, Bueracracy is NOT the way to fix a problem - It's even more ineffecient than the private sector... If the government had control over the internet, it would be quite a censored, wiretapped shithole, instead of the neutral ground that it is today. I don't think it would even be possible for the government to *get* control of the internet... and I *certianly* don't think it will be destroyed... not today, not tomorrow, not ever.

  • Re:Similar to telnet hijacking? (Score:3)

    by inburito ( 89603 ) on Thursday March 15, 2001 @07:33PM (#360359)
    Predicting ISN is more useful for pretending to be someone else. You can fake the originating ip-address and when server sends it's reply to the host you faked(which you of course will not receive) you acknowledge the connection by responding with a reply that contains a predicted server ISN(which you didn't receive).

    If the server is stupid enough to authenticate based on ip-address(rlogin, etc..) you could then compromise the server..

    Man in the middle doesn't have much to do with predicting isn as if you are in the position to intercept all traffic implementing it is fairly trivial with unencrypted connections.. Also if you are capable of intercepting all communications you could easily intercept the isn and thus fake to be someone else..

  • The pseudorandomness of random number generation via algorithms has been a point of concern for a long time in the crypto community.

    For the truly paranoid, several companys have products that generate random numbers based on the decay of a radioisotope. It doesn't get much more random than that.

    You can try one out [fourmilab.ch] on the Internet.

  • The "OSI Model" is just that, a model. (there is no such thing as "OSI protocols")

    TCP/IP is an implementation of various components of that model.

    OSI level
    Application (I will use telnet as an example)
    Presentation (eg. handled by telnet)
    Session (eg. handled by telnet)
    Transport (eg. TCP)
    Network (eg. IP)
    Data Link (eg. ethernet)
    Physical (eg. Cat5 UTP)

    Have a look at this page [lex-con.com]

    hth
    marty

  • and if you absolutely insist on doing IP based auth, implement _ANY_ kind of challenge response too! It can be as simple as IRC style

    server->client: "PING random_number"
    client->server: "PONG random_number"

    This will stop these basic blind spoofing attacks.

    This has been done already. Actually, its part of the TCP protocol. Its called the ISN of the server SYN/ACK. :o)

    Kiwaiti
  • No, it would be called IPSEC.
  • >All major OSI protocals use the mac address in their protocals for athentication. I believe its controlled in the nic's firmware and can't be overidden. A cracker can't make a fake mac wihout his or her own mac address bing automatically sent out.

    This is just plain wrong. Most NICs can have their MAC address changed by software. In Linux, for example, to change the MAC address of an Ethernet NIC, for instance, just:

    ifconfig eth0 hw ether 00:00:00:31:33:70

    Most NICs support this opperation, and I had already used it.

  • Sorry to take so long to reply! I've been in training, barf, and don't have quick and dirty generator with me. this page http://www.ozemail.com.au/~milleraj/misc/luxury.f9 0 [ozemail.com.au] looks like it has a better tested bunch of routines, which could return 64 bits with little modification. Note that the serries WILL REPEAT for a given seed. Also note that there are many free random number generators available on Linux and BSD platforms and that allmost any FORTRAN compiler will have a random number generator call that you can check out.
  • I don't know much about crypto, but I do know a little about generating random numbers.

    Random numbers that are useful are not really random. If they really were random, they could not be used to test out new systems and programs because you could not be sure you ran the same process to compare results! You can generate non repeating random numbers by using two numbers, a seed and modular division. The seed determines the next seed ad barf. For the same two numbers and seed on the same machine you will get the same answers every time. Using simple these simple methods and FORTRAN, I've generated billions of 64 bit non repeating numbers in a sequence.

    By using psuedo random numbers you can notice missing packets even with a strange looking serries of numbers. These numbers can change with machine and compiler though.

  • As I remember it, Windows can allow file access based on workstation, can't it?
    --
  • OK, true enough. There's still a _reason_ to put that apostrophe there.

  • I always thought that the usefulness of the OSI model as a tool for wrapping your head around TCP/IP networking concepts sucked, because the relationship was so strained. The TCP/IP model was sort of created after the fact, but is just as good at helping conceptualisation, and actually matches the protocols in use.

    Fundamentally we agree, though.

  • Sorry! There _are_ actual real OSI protocols, based on the OSI model. The TCP/IP protocols follow their own 5-layer model which has nothing to do with the OSI model. For some perverse reason, people keep trying to map TCP/IP protocols to the OSI model, and it doesn't exactly work.

    If you're using OSI protocols, then use the OSI model. Otherwise please bury it very deep, and never mention it again.

  • Re:What do you all think about using mac's? (Score:3)

    by swordgeek ( 112599 ) on Thursday March 15, 2001 @06:11PM (#360371) Journal
    Rant time.

    * An apostrophe does not mean, "look out, here comes an S!!!"
    * It's protocol, not protocal.
    * It's a lot, not alot.

    Now, onto the content. Does ANYONE use any of the OSI protocols? Everyone tries to map tcp/ip onto the OSI model, but the actual OSI protocols died as they were being created, if I remember.

    Also, most machines now allow you to change the apparent (and sometimes the actual) MAC address fairly easily. This is generally a Bad Thing, but makes it easy to spoof traffic authenticating by MAC address.

  • I still don't see that you can take over a TCP connection this way. Interfere with it, yes; see info from it, no. It's another way to do denial of service attacks.

    If you can make the guessing TCP sequence numbers hard enough, the number of attack packets needed to interfere with a TCP connection becomes high, high enough that the statistical schemes for locating denial-of-service attack sources start to work. So it's fixable.

  • If it's Stupid(tm), but it works, it isn't Stupid(tm). That having been said, that model breaks down as soon as you can't freely update your processes.

  • Robert Morris (Score:3)

    by regen ( 124808 ) on Friday March 16, 2001 @03:13AM (#360374) Homepage Journal

    Tim Newsham, senior research scientist at Guardent Inc., said that although the vulnerability he found in the Transmission Control Protocol is quite similar to one identified in 1985 by another researcher, it differs in several important ways.

    The original problem, discovered by AT&T Corp.'s Robert Morris, was that ISNs (Initial Sequence Numbers) generated at the beginning of TCP sessions to authenticate subsequent packets were predictable and could be used to create a forged connection between an attacker and a remote host.

    It is interesting that the author lists Robert Morris as working for AT&T. At the time that the orignal ISN vulnerability was found Robert Morris was working for the NSA not AT&T. At the time Robert Morris was the head of the NSA's computer security division. A few years later, he left the NSA after his son released a worm which took out a large portion of the Internet at that time.

  • WinGate [deerfield.com] runs on windows 9x ( but it is more stable on NT) and WinGate can be set to use IP addr. to grant privileges. (I have mine set this way)

    It's not clear to me if the SYN stuff on is better on NT than windows 9x.. Frankly, I'd love a replacement for WinGate that ran on linux. Even the NT box, with nothing else on it, randomly freezes after about 14 days.

    This worries me a little, Strikes me as possible the somebody could use this trick to get access/delete/modify files on my internal LAN.
  • There is such a thing - it's called Linux! :)

    I really, do want to agree, but I just can't. I use ipchains at home, and have no trouble with the little LAN I have there, but at home, I trust all the users.

    At work, I've got a much more complex system, For one thing, to get out on the web, users have to login to Wingate. ( the simple act of letting users know that logs exist keeps them in line)

    I have no clue how to do that with linux.

    It probably can be done, but I also don't have a spare week to figure out how to do it.

    Also, on the TCP weakness, if somebody hacked into my server, to make it seem like a Email death threat originated from here...(if it was POSTed as a web form the hacker really wouldn't need to see any data coming back). that could be a problem. Now this is a bit paranoid, but it occurs to me that if somebody actually did that, I'd have no way to show that I was a hacked.

  • Big Company's Solution (Score:5)

    by icqqm ( 132707 ) on Thursday March 15, 2001 @05:57PM (#360377) Homepage Journal
    Dear Valued Customers,

    I'm afraid the Internet will be going down for scheduled maintenance later today. Please log off and cease all activity between 3am and 4am GMT on Monday. Thank you for your understanding.
  • You could also sniff the packets, filtering by the IP of the machine you are looking to exploit. By watching the way the sequence numbers are generated, you can get a better guess at what the next one is going to be...
  • Most 3coms will let you reprogram your mac address. why, I haven't the foggiest idea, but you can. Also, there's no reason a cracker wouldn't be able to just modify the tcp/ip stack to send out a different mac address

    ---
    I'm not ashamed. It's the computer age, nerds are in.
    They're still in, aren't they?
  • So, suppose I figure out the ISN sequence for a TCP connection between two computers. Now how do I listen in? There's no way in hell I can sniff all of the trillions of packets that zigzag across the internet each day. Or even 50%. Or 10%. Maybe 1% if I have a somewhat central connection and a really, really capable router.

    This still isn't a big deal.

  • From the article:

    only reliable ways to guard the integrity of TCP sessions are cryptography...

    Meaning that most sensitive information is safe, since it is already encrypted by SSL/PGP/SSH. Anyone who wants to safeguard their communications is already doing this. And most of us sending things over the net non-encrypted realize that someone can intercept and read the data if they wanted to.

    As far as your comment on hijacking the current session, I believe the vulnerability is in impersonating a separate session entirely by guessing the ISN.

    Either way, since everyone is already encrypting important data, this is NO BIG FUCKING DEAL.

  • Well, as one who is at times mildy amused by the trolls around here(such as qpt) I was a bit disturbed with the story of a certain slashdot poster, Ryan Koppenhaver or something like that.

    Basically, he was an annoying guy and there were a few fake accounts ala Signal 11 or OlympicSponsor making fun of him. He managed to get ahold of one of these fake accounts by finding the password to it in one of the troll forums/sites. When he went to change his password, Slashdot dutifully emailed his IP address to the troll who made the fake account. They then did some basic tracking. They were able to glean his email address, his school, and finally his home phone number. Needless to say his website was DOS'd and his answering maching was left strewn with messages being the aural equivalent of goatse.cx.

    You can read all about it on geekizoid.com, a slashdot copy/troll site. Yep, its enough to make you want to be careful.

  • I don't believe that this problem affects either the Linux or FreeBSD kernels because they generate their ISNs from /dev/random which is considered to be quite secure (at least, as secure as you can get without an external hardware device to collect truly random information), therefore, these numbers are almost impossible to predict.

    According, to his attack summary [cert.org] he identifies a problem with kernels that increment the ISN value for each connection based on some predictable value. However, interestingly enough, he does not identify any systems that exhibit this vulnerability. Nor does he provide a whole lot of detail into how this vulnerability is any different than the ones that have been identified starting all the way back in 1996.

    In general, I think it is all part of a much larger problem that almost no OSes (except for Linux and FreeBSD) provide a kernel driver, such as /dev/random, to generate relatively unpredictable data. That kind of service is enormously helpful in all kinds of application, starting from the most obvious one - cryptography and TCP ISN selections to shuffling decks of cards in online casino games.

  • Details (Score:5)

    by Burning1 ( 204959 ) on Thursday March 15, 2001 @06:33PM (#360395) Homepage
    A basic TCP/IP Connection is created in this manar:

    Client > Server: "Syn"
    Server > Client: "Ack/Syn"
    Client > Server: "Ack"

    The host should generate an ISN when it returns the Syn/Ack packet.

    For each sequential packet, a new ISN is generated.

    For every packet the server sends the client, the client MUST respond with an ACK message, with the appropriate ISN. If the server does not receive this ACK, it will assume that the packet is lost, and re-try a couple of times before giving up. This is what gives TCP/IP it's connection based "guaranteed delivery" nature. Because of the ISN, it can detect lost packets, and can re-send them, allowing TCP/IP to work over connections with extreme loss (I'd say that it would still function with more than 95% loss, but, that is just a guess.)

    Beyond guaranteeing delivery, the ISN also provides security.

    Say that 4.1.1.1 is sending packets that are marked to have come from 100.2.2.2, to server 1.1.1.1.

    During the 3 way handshake (Syn, Syn/Ack, Ack,) all packets from server 1.1.1.1 would be routed to the correct destination (100.2.2.2,) even though they were actually from 4.1.1.1.

    Because 4.1.1.1 did not receive the Syn/Ack packets that the server (1.1.1.1) sent, it has absolutely no idea what ISN to respond with.

    Since 100.2.2.2 did not initiate a connection to 1.1.1.1, all packets from the 1.1.1.1 will be ignored.

    Now, let's say that 1.1.1.1 trusts 100.2.2.2 with a rsh root account, that does not require password authentication, when, and only when, 100.2.2.2 connects.

    With good random ISN generation, 4.1.1.1 will not be able to create any kind of connection to 1.1.1.1.

    Unfortunately, some operating systems, such as Windows, and Mac OS, generate terrible ISNs.

    With windows, you have a 1 in 7 probability of guessing the correct ISN. With Mac OS, you have a 100% probability of guessing the correct number (unless you are a fucking idiot. ;-)

    Even with the correct ISN, 4.1.1.1 will not be able to see any response to it's actions, HOWEVER, it could make enough correct guesses to log in as root, and install a root Trojan, allowing it to create a genuine connection to the server, under it's own IP address, resulting in a compromised box, and a !3e+ 5|<41|>7 k1<!dy with a big pudgy.

    I've also heard of loop back attacks, against a server. Utilizing Windows NT's weak ISN generation, and a couple of server daemons, there have been cases where people have managed to get 2 Windows NT services to initiate a connection to each other. As one generates errors, the other responds with errors of it's own, resulting in a feedback loop that eventually takes the server offline.

    Please note that I'm not a TCP/IP engineer. Feel free to correct any errors in this explanation.
  • I'd like to make a further point, which a lot of people seem to be missing...

    Yes, ISN-prediction enables spoofed TCP connections to be established. However, this is not the real problem . The problem is the use of protocols (rsh, rcmd) that rely solely on source-IP address for authentication.

    The first thing I do when installing Linux is to disable rsh, rcmd, etc... You should never allow someone to execute root privilege commands just because they appear to be coming from a particular IP address.

    A further point... so Winsock has easily predictable ISN's - big surprise. However, (correct me if I'm mistaken), but next to no-one runs rsh on Windows boxes, right? Exactly which TCP services is this exploit going to help you with on a Windows box? Does Windows provide services that are based only on source IP for authentication?

    I'm not defending MS's crappy Winsock stack - it has a number of worse problems than this - but I think that the value of this exploit has been greatly exaggerated.

    Strags
  • Assuming that the attacked machine is on an internal LAN, and that the trusted machine being impersonated is on the same subnet, you could certainly detect that the packets are being sent to you from the wrong MAC address (you would be receiving packets from LAN's gateway MAC, not the MAC of the machine being impersonated). That would alert you to something being awry.

    However, using MAC addresses for authentication only works if you don't decide to switch network cards. A far better solution is for the router/firewall to be intelligent enough to recognise that the incoming packet (coming from the Internet) has a source IP corresponding to a machine inside the firewall, and thus something's wrong. Many routers can be configured to discard such spoofed packets.

    Strags

  • Clarification (Score:4)

    by strags ( 209606 ) on Thursday March 15, 2001 @08:59PM (#360401)
    Firstly, ISN prediction is not telnet hijacking.

    In order to hijack a TCP connection, you have to sniff packets prior to taking control. In order to do this, you must be in a position such that you are able to intercept traffic between the two machines. Generally, this would entail being on the same LAN as the victim, or the machine he's logged into.

    So, what does ISN prediction actually enable you to do? Well, it allows you to form a TCP connection to a remote machine (X) that looks to X like it's coming from a 3rd machine (Y) instead of yours (A). Note also that this connection is one way - you can send information down it, but you don't get anything back. This is only useful as an exploit if (1) The machine you're talking to (X) is prepared to grant the 3rd machine (Y) special privileges, based solely on Y's IP address - in other words, a "trust" relationship exists between X and Y exists, and (2) The exploit doesn't require you to receive data back from X, and (3) The service you're connecting to on X doesn't require any additional password authentication.

    Many version of Unix ship with the rsh suite of services enabled by default. These services can be dangerous, because they can be configured to meet all of the criteria described above. However, most Unix TCP stacks employ fairly decent ISN randomisation, and thus are exceedingly tricky to exploit in this manner. (Mitnick's famous breakin to Shimomura's machines relied on rsh being available, and Shimomura running a TCP stack with no ISN randomisation to speak of.)

    On the other hand, Win98 has shockingly predictable ISN's. However, Win98 doesn't run rsh. In fact, Win98 doesn't run any services (that I'm aware of - someone please correct me if I'm mistaken) that (a) use source IP as an authenticator and (b) don't have some other kind of password protection.

    So, really, this isn't going to be too much of a problem.

    Strags
  • Maybe I'm missing something here, but why have we not yet implemented seamless, transparent crypto at some low level of TCP/IP? That way, even if people can spoof TCP headers and such, they won't be able to decode the payload of the intercepted packets. There is no reason why all the Windoze users out there who have never heard of crypto should not be protected by it just because they don't use PGP. Is there any reason why we cannot build crypto into the protocols used for ALL internet traffic (not just credit cards, etc)? Processing power is cheap, so I doubt that the excuse that it will slow net communications holds much water now.
  • Many Ethernet adapters allow the setting of MAC adresses. Some of them (see antique example above) don't even come with a MAC address. They are completely software based, and change MAC addresses after they get booted.
  • I think the story blurb needs to be worked on. This part can't be right..."...and his work has been confirmed by many sources as being a major problem in the implementation of TCP on many operating systems."

    I don't think that his work has been confirmed as being "a major problem" It looks to me that he seems to have discovered a "major problem"

    Regards Michael

  • The beauty of this attack is that you don't NEED to listen...Say there is a server I want to exploit a trust relationship with. Say I can predict the ISN it is going to give me. I will spoof a SYN from the machine with the trust relationship with my own ISN. The server says "oh this machine wants to establish a connection, I'll send my own ISN back" Now I can't see that ISN, but I do'nt care, because I can predict what it is. So I send back a constructed ACK packet, without ever seeing that SYN/ACK the server sent. The connection is "complete" and I send data to the target machine. That's how it works in theory, is it difficult to pull off? Yes! Is it impossible? No!
  • I can break into your car, your house, tap your phone, look through your trash to get info about you. I can kill you in your sleep.

    This is off the top of my head but I'm sure the list could be added to :) Just because I can doesn't mean I will though, just as most people woudn't.

    Computers and the Internet mirror our individual lives and our lives as a society (respectively) and as they guy from CDC said once (Rob something, I forget his name...) "Life is messy, so's the Internet". Say, since I have like 6 or so computers does that mean I have multiple personalities?
  • Hmmmm. How old it TCP now - 17 years or so? And we're still turning up fundamental flaws in the protocol design. It seems to me (and no, I haven't read Stevens, so I probably don't know what I'm talking about [g]) that either:
    • The basic design of TCP and/or IP was really bad; and/or:
    • The problem domain is Hard (in a mathematical sense); and/or:
    • The "many eyes make all bugs shallow" shtick is fundamentally wrong.
    A colleague who actually has a CS degree mumbled something about "I'm amazed that IP is still going, should have been replaced by something better ages ago..." - anyone knowledgable care to comment on that? (We went down a big tangent about VHS and Microsoft, and the syndrome of poor technical solutions getting locked into market dominance through marketing, happenstance, first mover advantage etc.)

    Finally, I'm a bit surprised that (cliche alert) this is *news* for nerds. The ISN problems have been talked about on Security Focus, Bugtraq, nanog et al for a week or so now.
    --
    If the good lord had meant me to live in Los Angeles

  • Whatever the particulars, this hole is still an old problems, though one not taken serious enough by people who should know better.

    I remember talking to Term-X^H^H^H^H^H|||^H^H^Hal^H^H Tim Newsham about the problems of properly seeding PRNGS for security while on IRC (#hack on efnet...cut me a break, I was young and stupid) years and years ago.

  • Similar to telnet hijacking? (Score:4)

    by sleeper0 ( 319432 ) on Thursday March 15, 2001 @06:23PM (#360432)
    I thought that the threat of telnet hijacking was very real. While switching to ssh makes sense for privacy and password sniffing, I was under the impression that one of the best benefits of ssh over telnet with one time passwords was the probability of session hijacking

    I am no script kiddie but I thought I had even seen tools available for download that would do just that. If these have been around for years then how do they differ from this revelation?

    The article at eweek [zdnet.com] that the post seems to refer to seems to give more details about the attack.

    It says:
    "ISN values are exchanged by the sending and receiving hosts and are supposed to be chosen randomly. Each successive packet then contains a sequence number that is based on the ISN plus the number of bytes transferred to the receiving host.

    But if the ISN is not chosen at random or if it is increased by a non-random increment in subsequent TCP sessions, an attacker could guess the ISN, thereby enabling him or her to hijack the session's traffic, inject false packets into the stream or even launch a denial of service attack against individual Web servers."

    So they seem to say the problem is not that the initial ISN isn't created randomly, it's that the subsequent numbers aren't incremeted randomly (wouldn't that be hard to do?) but are rather incremented by the number of bytes transmitted. IF you observe the session and count the bytes on a couple of packets, you can figure a number to use to continue (hijack) the session.

    I guess there must be an additional bit to it considering the details haven't been released. Can anyone comment that knows more about the issue?

    Anyway, my only point with telnet was that I thought it was already commonly accepted that encryption was the only thing that was going to stop hijacking. I guess this may get proved out

    Sleeper

  • Someone call Al Gore, he'll fix it

Slashdot Top Deals

The question of whether computers can think is just like the question of whether submarines can swim. -- Edsger W. Dijkstra

Close