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