TCP Weakness No False Alarm? 144
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."
Re:Still short on details (Score:1)
A Long Time Ago.... (Score:1)
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)
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)
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)
Re:What do you all think about using mac's? (Score:2)
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)
Re:Similar to telnet hijacking? (Score:1)
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.
Re:What do you all think about using mac's? (Score:1)
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)
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.
OT: Government control of the Internet (Score:2)
- 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.
Re:Many eyes == shallow bugs? (Score:2)
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)
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 :-)
Solutions exist (Score:1)
http://ippersonality.sourceforge.net/
Re:The Dangers of Guessable ISN's (Score:1)
Re:Similar to telnet hijacking? (Score:1)
"Insider" security (Score:1)
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'.
--
Re:Clarification (Score:1)
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......
Re:still kind of old... (Score:1)
Reprogramming the MAC address (Score:1)
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.
Re:Surprise surprise. (Score:2)
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
--
Re:The WORLD has security flaws! and other randomn (Score:1)
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.
Re:not to pick a nit ....but..... (Score:2)
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.
Re:Details (Score:1)
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
Predict a pseudo-random-number generator? (Score:2)
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.
Re:What do you all think about using mac's? (Score:2)
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.
Where's the spotlight? (Score:2)
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?
Re:Clarification (Score:2)
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.
Re:Big Company's Solution (Score:2)
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.
--
Re:Similar to telnet hijacking? (Score:2)
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)
Re:Details (Score:5)
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.
It isn't a problem with the PRNG (Score:1)
seed and modular division? (Score:2)
thanks!
What 'major OSI protocols' are those? (Score:2)
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
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.
Re:The Dangers of Guessable ISN's (Score:2)
Re:The Dangers of Guessable ISN's (Score:3)
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)
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.
Re:Strong crypto in the TCP stack (Score:2)
--
Re:Crypto (Score:2)
You can really notice when they're trying to encrypt a full 2Mb/s of traffic. Mind you - they are only Pentium II machines.
Re:Details (Score:1)
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...
Re:A question... (Score:1)
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!
Re:The internet is BIG (Score:2)
Re:What do you all think about using mac's? (Score:2)
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.
Re:Surprise surprise. (Score:1)
Random ISN's (Score:2)
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.
The award for most useful 70's chic goes to: (Score:2)
It is always good seeing SGI at the forefront of technology:)
Frog51
Re:Strong crypto in the TCP stack (Score:1)
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
Re:Details (Score:1)
Re:Still short on details (Score:1)
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?"
Still short on details (Score:2)
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.
Re:What do you all think about using mac's? (Score:1)
Re:What do you all think about using mac's? (Score:1)
Re:Many eyes == shallow bugs? (Score:2)
Re:The WORLD has security flaws! and other randomn (Score:1)
The WORLD has security flaws! and other randomness
Oh the irony!!!
Re:A question... (Score:2)
[TMB]
Re:Surprise surprise. (Score:1)
Re:A question... (Score:1)
Re:Details (Score:1)
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.
Re:Surprise surprise. (Score:1)
Crypto (Score:3)
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)
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)
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..
Robust random number generation in hardware (Score:1)
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.
Re:What do you all think about using mac's? (Score:1)
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
Re:Details (Score:1)
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)
KiwaitiRe:Strong crypto in the TCP stack (Score:2)
Re:What do you all think about using mac's? (Score:1)
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.
Re:seed and modular division? (Score:1)
psuedo random is how (Score:2)
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.
Re:Details (Score:1)
--
Re:What do you all think about using mac's? (Score:1)
Re:What do you all think about using mac's? (Score:1)
Fundamentally we agree, though.
Re:What do you all think about using mac's? (Score:2)
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)
* 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.
Limited exploit (Score:2)
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.
Re:The award for most useful 70's chic goes to: (Score:2)
Robert Morris (Score:3)
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.
Re:Clarification (Score:1)
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.
Re:Clarification (Score:1)
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)
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.
Re:The internet is BIG (Score:1)
Re:What do you all think about using mac's? (Score:1)
---
I'm not ashamed. It's the computer age, nerds are in.
They're still in, aren't they?
The internet is BIG (Score:2)
This still isn't a big deal.
Re:Still short on details (Score:2)
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.
Re:Surprise surprise. (Score:2)
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.
Not a problem in Linux (Score:2)
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
Details (Score:5)
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.
Re:Details (Score:2)
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
Re:What do you all think about using mac's? (Score:2)
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)
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
Strong crypto in the TCP stack (Score:2)
I will fire up my old Vax 11/70 and own you.... (Score:2)
not to pick a nit ....but..... (Score:2)
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
Re:The internet is BIG (Score:2)
The WORLD has security flaws! and other randomness (Score:2)
This is off the top of my head but I'm sure the list could be added to
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?
Many eyes == shallow bugs? (Score:2)
- 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
still kind of old... (Score:2)
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)
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
Al Gore? (Score:2)