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."
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.
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.
- 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.
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).
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 :-)
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
--
Vidi, Vici, Veni
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.
I like to play children's songs in minor keys.
"We're all sons of bitches now." --J. Robert Oppenheimer
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?
now we need to go OSS in diesel cars
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.
now we need to go OSS in diesel cars
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.
--
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
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?
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.
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!
cpeterso
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.
/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.
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.
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.
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.
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.
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.
Slashdot - News for Herds. Stuff that Splatters.
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. The coolest random number generator on the web since 1996!
It is always good seeing SGI at the forefront of technology:)
Frog51
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.
The author of "Interconnections" (reviewed here earlier this year) mentions that IPX+ would have made a much better backbone to the Internet.
- Michael T. Babcock (Yes, I blog)
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]
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..
No, it would be called IPSEC.
-no broken link
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.
Friends don't help friends install M$ junk.
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.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
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
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.
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]
This still isn't a big deal.
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.
No, Thursday's out. How about never - is never good for you?
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.
/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.
According, to his attack summary 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
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.
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
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.
*whup* "Get along, little electrons. Heeyah!"
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
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.
:) Just because I can doesn't mean I will though, just as most people woudn't.
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?
- 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
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.
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
Someone call Al Gore, he'll fix it