Slashdot Mirror
TCP Weakness No False Alarm?
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."
A reasonable summary is available at http://www.kb.cert.org/vuls/id/498440
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.
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 :-)
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.
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.
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.
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.
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.
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.
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..
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.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
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.
The Economics of Website Security
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.
icqqm [ICQ:11952102]
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.
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
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 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