Slashdot Mirror
Security Hole In TCP
Ant wrote to us with the
report from eWeek concerning Guardent's find of a "potentially huge problem" in TCP. It's very similar to the hole found in some of the Cisco IOS software, concerning the ISN and the assignment of the number.
...as it is being made out to be.
This will only fully hijack unencrypted transmissions, and only if the hacker can predict the ISN sequence. It's made easier if the seed isn't random, but it's a long way from being a major threat, and it's not an unknown threat--many TCP/IP stack implementations are not vulnerable.
Returned Peace Corps IT Volunteer
Yet another security vendor tries to get press by reminding everybody of something that's been out there for years.
(Looks like it worked.)
I had a look at the site but couldn't see if this was taken into account, unless an allowance is made for this the spread of numbers will change over time. Admittedly this is theoretical and it should be random enough in the short term, but I'm not sure it's random in the long term.
----
I hereby inform you that I have NOT been required to provide any decryption keys.
As a computer security consultant, this story seems silly to me.
.rhost that trusted another one. Kevin spoofed packets from the trusted computer to execute a "echo '+ +' >> /.rhosts" then just rlogin. To help the attack Kevin also SYN flooded the the trusted computer so that it would not respond with RST packets. This type of attack is called blind spoofing and is usually difficult to do. There are programs out there that will do this. ie: ADM-rsh
see CERT advisories dating back to 1995... as well as bugraq discussions about it...
This is a very well known "vulnerability". The most famous use of this vulnerability was by Kevin Mitnick to attack Tsutomu Shimomura's computers.
Basically one of Shimomura's unix boxes had root level
Tools like nmap test for ISN randomness. Just about all unixen are atleast pseudo-random, which makes the attack almost impossible to do to two computers that you can't sniff traffic to or from.
If you can sniff traffic from either box then the problem of hijacking connections becomes much simpler. At this point it doesn't even matter what the ISNs are because you can just sniff them. Tools like: hunt are the preferred tools for session hijacking. hunt even has ARP spoofing so that you can sniff over switched enviornments.
I'd have to ask for a reference on that one. I've seen several arguments, including Bell's Inequality, but none which make so broad and definitive a statement. (ex: this)
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
It was a case of IP spoofing against Shimomura. While he couldn't see results (IP spoof after all) the ability to guess ISN's allowed him to play the role of one of the computers involved in the transaction.
Not my original source, but it does make mention of the story
_______
2B1ASK1
... Since 1992. l0pht was one of the first sites to discuss (and expose) security issues publicly on the Web (other than CERT).
ALL events can theoretically be traced back to a specific cause.
Wrong. Quantum events are inherently random and not predictable. All you have to do is to amplify such events into strings of 0 and 1. One example is radioactive emissions -- if you can keep the source and detector in the range where you count one particle at a time. That's rather difficult to do in a way that's both safe and will keep running without adjustments. Another possibility: resistor shot noise, which originates in the fluctuations as individual electrons pass through the resistor. I am not good enough at analog design to figure out just how to use that, but it should be possible to generate random numbers from shot noise in a small circuit with common parts.
If you are generating pseudo-random numbers entirely from software, then it is predictable, if you can guess the formula used. The simple formulas you'll find in pre-packaged "random number generator" subroutines are probably easily guessed. Go to a cryptographer and you can get formulas that are alterable by plugging in a secret key of hundreds of bits, so even if the basic formula is publicly known, guessing the key takes enormous computer power...
I think you're confusing two different security concepts.
.rhost that trusted another one. Kevin spoofed packets from the trusted computer to execute a "echo '+ +' >> /.rhosts" then just rlogin. To help the attack Kevin also SYN flooded the the trusted computer so that it would not respond with RST packets. This type of attack is called blind spoofing and is usually difficult to do. There are programs out there that will do this. ie: ADM-rsh
Inital Sequence Number guessing is only useful for spoofing "new" connections or blind spoofing. Thus the "Inital" part of the term. Basically you are blind spoofing communication between A and B (while your are C), to take advantage of some trust relationship between A and B.
As pointed out in many posts this attack was done by Kevin Mitnick. Basically one of Shimomura's unix boxes had root level
Session Hijacking is what you are reffering to. This is taking over an already established connection. In this attack you use the fact that you can sniff or obtain the sequence numbers already in existance by an extablished TCP connection and inject spoofed packets to interupt or tack of that session. Tools suchs as hunt do this type of attack.
Bruce
Bruce Perens.
But that doesn't mean it's not threatening. On the contrary, it's important to point out that TCP connection resilience is critical to the Internet infrastructure. TCP connections carry the BGP4 inter-ISP peering traffic that routes the backbone.
By and large, there's not a whole lot of meaningful things you can do with TCP spoofing (even RSTs) on a clueful network. But there are infrastructure protocols that rely on TCP and major havoc to be caused if they're disrupted.
There's been an unofficial understanding that router TCP stacks are not very robust. If ingress filtering isn't set up correctly, you can use flaws like this to disrupt peering sessions between routers. This is terrible. But Guardent could stand to be less hand-wavy and more forthcoming about their analyses.
I think Bruce Perens could stand to be a little less glib, and pay a little closer attention. This appears to be valid research, blown out of context by PR. It happens, it sucks, but we shouldn't add to the problem by using the bad PR to obscure the threat.
So, where's the story?
...and we all know where to find the 'big ass without add'-version, don't we?
www.goatse.cx, of course!
-- Cure for Cancer instead of SETI! (only w32 yet - mail and beg)
This is just some company's PR trying to get themselves noticed. This is NOT A NEW DISCOVERY (as many others have already pointed out).
L.Ron Bumquist of the ETLA Group today announced that he had found a major vulnerability in nearly all home security systems. If the security system is made from delicious Norwegian Jarlesburg cheese instead of wires and computer chips and stuff, a potential burglar could enter the house undetected.
/dev/random and /dev/urandom) for choosing and incrementing TCP sequence numbers.
This is why any reasonable TCP stack uses good random number generators (like our friends
This story is nigh-on useless. Ignore it.
Just because you can get it a catchy and unthreatening name like 'water' doesn't make it any less deadly. I mean, I can call 'dense combinations of DHMA vapor, CO, CO2, and unburned hydrocarbons trapped by atmostspheric inversion' 'sparkle' instead of 'smog', but that doesn't make it any more breathable, does it?
-David T. C.
If corporations are people, aren't stockholders guilty of slavery?
a) very hard to do, and
b) rather limited in practical damage-causing.
This issue is more founded in a company trying to make a name for itself by announcing a "huge" security flaw but it also appeals to the public at large to imagine that there might be some terrible hole underpinning the electronic revolution (like as in Y2K or the fuss around some dot.coms going belly up). Besides, this isn't a hole so much as a feature that can be used in a negative way. I don't think the possibility of doing this went unobserved by the hundreds of people involved in developing TCP.
Geoff
Thanks guys, two good resources there for anyone who needs _really_ random numbers.
It is kind of like trying to prove something can't be done.
------------
CitizenC
Umm, when was the last time you saw a scr1pt k1dd13 tool posted to 2600. DeCSS, arguably (and I would argue not, but whatever). 2600 is more of a political/news site, not a script kiddie outpost.
------
Not a typewriter
Things are not random at the quantum level. We have been able to prove that. The problem with the quantum level is that they fall below our significant digits and thus, we have a tendency to round it off and treat it as random. If you go down infinitely far, it is 100% predictable. The problem is, who really wants to go down that far to predict the exact number a person is going to pick from 1-10.
You stupid bastard, you don't have no arms left. It's just a flesh wound.
Actually, thigs are *fundamentally* random at the quantum level. The exact position of any given particle is not exact - it is a probability wave.
-- Give me ambiguity or give me something else!
Some people may think its a joke, but the levels of DHMO in humans has been staggering the last few years. I hear it becomes most serious on the weekends. Please be careful of the consumption of beverages that may contain significant quantities.
Christ why are people modding this as funny! It should be +5 Insightful! Spread the word!
"And like that
Sloppy thinking. All traffic is data, though some is transmitted in larger bursts than other. A TCP connection carrying Telnet data (not a "terminal session") is the textbook example of traffic that should be buffered using Nagle's algorithm to avoid sending one packet per octet. The user's keystrokes will determine how far the outgoing sequence number is eventually incremented (unless the client does Telnet negotiation or sends urgent data), but guessing how many octets the server will respond with is another problem (as is preventing the client from resetting the connection once you've injected more than one window of data).
Although it is fun to pick on Microsoft and Windows, these are not the results I recieved when nmapping win2k boxes.
Windows 2000 Workstation:
TCP Sequence Prediction: Class=random positive increments Difficulty=232626 (Good luck!)
Windows 2000 Server:
TCP Sequence Prediction: Class=random positive increments Difficulty=22436 (Worthy challenge)
Didn't have a Windows 9x box handy to try it out on but maybe this is what you have done.
I assume this must change after every nmap, but why would the workstation be seemingly more secure than the server machine? I guess that's just Microsoft's way of doing things... The other curious thing I stumbled upon is the fact that the Windows 2000 Workstation was not recognized by this scan, it returned that no OS matched the host. Maybe this explains why it is so high, maybe it isn't Win2K after all, mind you I seem to be using the machine at the moment. Hmmmm......
Just about anyone can drive down it, right to your door!
So lock the door, dummy.
I'm no expert on TCP, but I think that anyone who cares about security at all already knows that it's not secure, it was not designed to be secure, and it never will be secure by itself. If you need security, you pile it on top of TCP/IP, by encrypting packets, etc.
So, is this really a big deal?
(btw - fp.)
"This is extremely difficult to do. It's a theoretical attack," said security expert Steve Gibson, of Gibson Research Corp. in Laguna Hills, Calif. "It's weird that they're talking about something like this. It's as old as the hills."
And that's from the article, itself...
At least Guardent (or what ever it is..) suckered ZDNet into giving them some space in the news hole...
t_t_b
--
I think not; therefore I ain't®
I'm on PJ's "enemies" list! Are you?
Not only that, but around 1997 or so there were tools floating around that used this trick specifically against IRC servers. IRC servers simply started sending random numbers in their "PING" messages, and dropping people who didn't have the same number in their "PONG." Since when you were spoofing, you couldn't see the return packets, you couldn't respond correctly.
Finally, the problem was fixed for real at the OS level in almost every OS in late 1998 or so. Unpredictably random ISNs and increments are quite common. The popular tool "nmap" can even scan a machine and tell you how unpredicatable its sequence numbers are. Non-microsoft OSes (and win2000) generate sequence numbers quite securely.
This is very old, non-news. The best quote in the whole article is the security expert who points out that this has been known pretty much forever, was fixed 5 years ago, and the fix was widely deployed over 3 years ago.
Some people may think its a joke, but the levels of DHMO in humans has been staggering the last few years. I hear it becomes most serious on the weekends. Please be careful of the consumption of beverages that may contain significant quantities.
Of course, the air has contained that much Nitrogen for the entire existence of the human species. And this TCP security problem has existed nearly as long, and has had about as little effect on your life. People fix this by improving their random number generators. Big deal.
Bruce
Bruce Perens.
Really, Bonker, is it necessary to insult our fellow primates, the Chimpanzees, by comparing them (even favorably) to a group of attention-hounding, press-seducing, history-ignorant, technogonadless marketers?
2.1.53 would have been an unstable kernel anyway. SMB is bloated all on it's own, made worse by Microsoft. How could it not have huge, unknown bugs?
------
Not a typewriter
These people are obviously lame and trying to get fame reposting twenty year old stuff. There is, however, another issue that hasn't been addressed. There are only 2^16 possible sequence numbers. When we all used 64K links, you could only guess a few of them, but as everyone moves to fatter pipes, you get more guesses. On an OC-48 is becomes almost deterministic to guess the sequence number.
Urizon Technology released a security advisory today outlining the potential pitfalls for security telephony. "Why, just any joe with a Radio Shack speaker-amp and a pair of clip leads can walk up to a patch panel and evesdrop on phone calls!" reported Clive Doppler of the "Urizon Group Grappling with Security" (UGGS) department. Urizon stock closed at 47.46, down 0.28.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
You might find some good info from the creators of Samba. From what I've heard, they actually did find a huge number of security holes in the protocol. If there's docs for any of them, they'll be at http://us1.samba.org/samba/docs/
Engineering and the Ultimate
> I mean - technically nothing can ever be absolute (we can't be sure
> 1+1==2; we've just observed it throughout all of recorded history)
Oh yes, that's been proved. Take a graduate measure theory course, or maybe even an upper division undergraduate theory course. You start with the notion of a "something"--a scratch, a stick, a whatever, and build from there.
On the other hand, proving that an observed phenomenon actually corresponds to the derived "1" or "2" is another matter, but you can certainly prove 1+1=2 from the ground up . . .
hawk
2.) How hard can it possibly be to generate a random number, even for a simple OS installed in a router?
...don't usually do the work needed to create an unguessable (secure) random number...
:
You're talking about pseudorandom numbers there. Random numbers simply cannot be "generated". Although there are several secure pseudorandom number generators, but one shouldn't mix them with real randomness. (Take the unix C random() for example, it's initialized with 32 bits and thus it's entropy can never exceed that. Same goes for famous stream cipher RC4 (the internal state is 256bytes but still) and all others aswell.
To create truly random numbers one needs an entropy source. Computerwise there are few handy ways to get real entropy into the pseudorandom number generators, here are few examples
1) They sell hw cards that have cold radioactive sources and detectors in them. Radioactive decay after all is as random as it gets.
2) Unplugged line-in jack has static which has several random bits in it. When undisturbed, it can be concidered random.
3) The already mentioned web cam pointed to a lava lamp.
4) On UNIX systems the process table can be concidered to have some randomness in it, but one shouldnt screw up with that one either. It has atmost 10-20 bits of randomness when also measured relatively seldom.
5) User key typing or mouse motion
1 Earth is warming, 2 It's us, 3 it's royally bad, 4 we need to take action NOW
It is nice to have somebody actually explain what is going on, and describe how an attack would work tho. For years, nmap has spat out this 'sequence prediction', 'difficulty', and an accompanying description,and nobody had any idea what it was, and the nmap docs never mentioned it either, but it took up most of nmap's output so it looked pretty important.
Now we know that it is merely these 'packet IDs'. I'm sure many people have pointed out that guessing these is not really much of an attack, as spoofing packets is nothing new, and people use encryption for anything important -- and encrypted data is not vulnerable to this attack.
Again, IIRC, OpenBSD's stack uses some of the best random numbers (as shown by nmap when it tries to predict the OS of the target.)
Other than that, thanks :) I was curious as to why OpenBSD was rated so much lower. (although it's all relative)
Background research for slashdot? What a strange idea. :)
-skip
They need to generate cryptographically secure random numbers, which are a bit more complicated and in-depth than the (most likely) time/state-dependant PRNG used in the AppleIIe.
It's still easy if you do the research, but to assume that they're the same thing is wrong.
--
Soma: because a gramme is better than a damn.
WINS (Windows Internet Name Service) by itself *is* TCP/IP-based and requires the client to know the IP address of the server, in order to be of any use. Other netbios naming services that run on other protocols are not "WINS". Yes this is a nitpick.
>>At the quantum level, things are fundamentally random
are you kidding me? at the quantum level, things are very NOT random. read some quantum mechanics, or better yet, some quantum theory pertaining to computing. the idea is that with supperposition and entanglement we can predict, with reasonable certianity, the outcome of a quantum coin toss. quantum computing would not exist if we couldn't.
Website Hosting
Interesting ports on boris.ST.HMC.Edu (134.173.xxx.xxx):
You know... if you're gonna mask out the ip, better mask out the host name as well cause DNS doesnt lie! (Well, usually it doesn't)
cat /dev/clue | /slashdot/editor
or just leave the cat alone
Allow me to meta-edit *grin*
s/chimpanzee/gibon/
Even Einstein didn't much like the statistical models that Planck and others were coming up with... But the quantum universe wasn't exactly his field.
Besides, having true randomness in the universe gives us a warm fuzzy feeling... there really is free will! Our fates are not predestined.
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
#nmap -O hostname
OpenBSD 2.8:
TCP Sequence Prediction: Class=random positive increments
Difficulty=28836 (Worthy challenge)
Remote operating system guess: OpenBSD 2.6
Digital (Tru64) UNIX 4.0F:
TCP Sequence Prediction: Class=random positive increments
Difficulty=355 (Medium)
Remote OS guesses: Digital UNIX OSF1 V 4.0,4.0B,4.0D,4.0E, Digital UNIX OSF1 V 4.0-4.0F
Linux 2.2.18:
TCP Sequence Prediction: Class=random positive increments
Difficulty=3738947 (Good luck!)
Remote OS guesses: Linux 2.1.122 - 2.2.14, Linux kernel 2.2.13
I don't have much else to test, but it seems to me that the Linux TCP/IP stack uses significantly better random numbers than OpenBSD, as shown by nmap. I'd wager some others do too.
-skip
...or if you have a *really* big "dictionary".
All your event are belong to us.
From the article: However, any attacker looking to exploit this vulnerability would likely have a hard time, security experts say. Not only is it inordinately difficult to identify machines that are vulnerable, but the attacks themselves are quite hard to execute.
And because the flaw has been known for so long, it's unlikely that there are many TCP implementations that are still vulnerable to such attacks.
Isn't this just standard TCP/IP number sequencing for the packets? IIRC there was a problem with Free BSD sometime back in that the TCP/IP stack had a bug where the sequence numbers were not truly random and could be spoofed quite easially. Again, IIRC, OpenBSD's stack uses some of the best random numbers (as shown by nmap when it tries to predict the OS of the target.) and predicting and spoofing those packets is nigh impossible.
Is this just the same old hole or am I missing something here?
Try to hack my 31337 firewall!
Kiddi3z will always be a nuisance, but my personal feeling is that the parties responsible for the death of the Internet will be a handful companies trying to milk or control it...
(end comment) */ }
(end comment) */ }
[an error occurred while processing this directive]
take nmap, for example.
A simple run on a freebsd 4.2 box yields:
[1:37pm] root # nmap -O boris
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on boris.ST.HMC.Edu (134.173.xxx.xxx):
(The 1513 ports scanned but not shown below are in state: closed)
Port State Service
21/tcp open ftp
22/tcp open ssh
23/tcp open telnet
25/tcp open smtp
80/tcp open http
110/tcp open pop-3
111/tcp open sunrpc
143/tcp open imap2
587/tcp open submission
3306/tcp open mysql
TCP Sequence Prediction: Class=random positive increments
Difficulty=17911 (Worthy challenge)
note: random positive increments
Now, the same scan on a win2k box yields:
[1:40pm] root # nmap -O skittles
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on skittles.ST.HMC.Edu
(134.173.xxx.xxx):
(The 1518 ports scanned but not shown below are in state: closed)
Port State Service
21/tcp open ftp
80/tcp open http
81/tcp open hosts2-ns
139/tcp open netbios-ssn
3306/tcp open mysql
TCP Sequence Prediction: Class=trivial time dependency Difficulty=2 (Trivial joke)
Remote operating system guess: Windows NT4 / Win95 / Win98
Thus, guessing tcp sequences isnt entirely difficult for windows 9x boxen, its just that its generally easier to exploit other problems than play with tcp stacks.
Mooniacs for iOS and Android
The saying does go:
It is best to keep your mouth shut and appear ignorant, than to open it and remove all doubt.
Someone should have made them aware of this fact.
Hardware random number generation is pretty easy. Just amplify the thermal noise and use that as a driver signal. It appears to be totally random, and sufficiently dense to create a lot of new keys. You could also monitor the background radiation. If you just need a short key and don't want to hardware hack (I sure don't), monitor the time between keypress events, or disk accesses (whatever's easy, fast, variable, and unrelated to the problem).
Usually it's quite sufficient to feed your pseudo-random generator a new seed every few minutes. Actually, even that is usually overkill, but now we're getting to the practical rather than truly random.
Caution: Now approaching the (technological) singularity.
I think we've pushed this "anyone can grow up to be president" thing too far.
Just read the quote, it states: "these numbers are guessable on many platforms" - which means that there are "many" platforms which have insecure random generators, and so it is guessable on those. The other which have secure random generators haven't guessable ISNs, and so are secure.
plim-plam-plompudding
Diodes if biased properly are noisy. Transisters are noisy. You would think with millions of pn junctions laying around in the typical computer chip some of them would be noisy!
They ARE out to get you simply because They are in it for themselves and they don't care about you.
Heisenberg was an idiot.
You stupid bastard, you don't have no arms left. It's just a flesh wound.
Your telling me that you're going to use non-random inputs in some non-random formula to make a random number. This number would not be random, it could be predicted if one would follow every single possible path that led to the exact events and timing that led into the production of that number. This is extremely hard to predict but in no sense random.
You stupid bastard, you don't have no arms left. It's just a flesh wound.
Two questions - 1) if this "problem" has been around since the mid-80's why has it never been exploited? Actually, according to Shimomura's rather self-obsessed book "Takedown", this is one of the attacks that Mitnick used to exploit the trust relationship between two of Shimomura's machines. Anyway, this really is old news... these days, a good OS generates randomness based on extremely unpredictable external values, such as the number of microseconds the hard drive took to read the last sector, for example - thus rendering a hacker pretty much helpless to predict the next ISN. The main use for ISN prediction as a hacking tool is to spoof TCP packets such that they appear to be coming from a trusted source IP address. Although this problem has been adressed in all worthwhile TCP stacks, it is still bad practice to rely solely on source IP as an authentication method. Strags
They also failed to point out why this has never been a significant problem - ever. In order to assume any established connection, you'd have to be one the same cable or somewhere in the path (read: "man in the middle") You cannot steel any random connection on the net. In fact, it's become rather difficult to nuke 3rd party connections -- send an ICMP unreachable message to close down a connection between two distant machines (presumablly when you aren't in the path.) This was the tool of IRC channel/nick theives in the 80's :-)
And yes, you can assume the connection in any case if you are on the cable or in a direct path where you naturally see the traffic in both directions. I had fun one evening (yes, it's that easy) modifying my linux box (486dx50 running 0.99pl15 at the time) to "flash establish" a socket and assume the telnet session from my mac.
Pinball Wizard asked, "if this "problem" has been around since the mid-80's why has it never been exploited?"
It has been. To cite the best-known example, this vulnerability is what Kevin Mitnick used to break into Tsutomu Shimomura's computers, which triggered Shimomura's vendetta, and eventually led to Mitnick getting caught and spending several years in jail.
I guess it's one of those deals where corners are cut because the manufacturer figures the exploit is too hard to ever become widespread.
Bad juju for the end user when someone proves them wrong.
If Godzilla did not exist, man would have had to create him.
gotta say, this hole really reminds of a message that was recently forwarded to bugtraq.
(taco, your lameness filter sucks)
SERIOUS VULNERABILTY AFFECTS ALL VERSIONS OF UNIX AND WINDOWS
A serious vulnerability has been found in all versions of
Unix and Windows. This problem most likely affects all
other systems as well.
It has been found that computer systems must be physically moved
prior to installation at a computing facility. Moreover,
when these systems are transported, they are usually moved
at some point by human beings.
Obvious insecurity Inc. has found that a serious DOS attack
can be waged on these systems when attackers stand on top of a building
high above the area where a system is being moved at the proper
time interval.
The attackers toolkit consists of a long range flamethrower,
a large sledgehammer, and concussion grenades. If the attacker
has perfect timing, they may drop the sledgehammer/light the
flamethrower/drop the grenade onto the target system in
question, thereby creating a DOS condition.
This scenario can be spread easily through a coordinated
attack, but this has yet to be seen in the wild.
Vendors have been notified 1.5 minutes ago, but have so
far proven that they are incompetent by not releasing
patches or sending a reply to our email. Therfore, in
the interests of full disclosure, we are making these
shocking results public, since YOU have a right to know.
This earth shaking, trend setting vulnerability has been
discovered by Obvious Security Inc. We hope to overwhelm
bugtraq and the other lists with our skills so we can
make more money and have more prestige in the computer
security industry.
Remember - "Just because it's right in your face, does
not mean that it's obvious".
Obvious Security Inc. Bulletin #2600
And in other news...Security expert Joe Blow made the stunning annoucement that theoritically peoples Unix accounts could be hacked if the chose a word in the dictionary. Joe say, "Yes I know this has been known for some time, and most Unix implementations take care not to allow dictionary words, but I just wanted to be safe and let others know of my discovery". Joe Blows comany, Obvious Fixes, sells software to resolve this issue.
Burn Hollywood Burn
So they're saying that if you can predict the port number that will be assigned to a session, you can hijack it?
Hello? When was this not known? Tell us something we don't know!
Linux for instance uses random positive increments. No number is truly random, but many are "random enough".
That is to say, it's Really Hard to predict the port number, hard enough that trying some other vounerability would be more rewarding.
This is a non-story. Hackers and security experts have known about this so long that many have probably forgotten it several times by now. All this muckrake serves to do is alarm the chicken littles.
This is just like television, only you can see much further.
There is no problem, today, to hijack a connection once you can sniff it. The tools are there.
Question is will there be tools to hijack a connection and inject data into it when you can't sniff it. Unpredictable (not necessarily 'purely' random) come into play here, and since it is 'as old as the hills', most TCP implementations already do some sort of activity to make it so. Not that hard to do.
All the best
---
Civilians: Someone set up us the bomb.
Check out http://insecure.org/nmap/
The article states that this is a well known problem, that they knew about this problem since the mid 1980's... so...
how in Gods green earth does this qualify as news in any way shape or form...
its kind of like saying "Beware the RTM worm..."
DOS is dead, and no one cares...
DOS is dead, and no one cares...
If there's a Bourne Shell, I'll see you there
These are all results from NMAP
---- My Windows 2000 Pro box w/SP1
TCP Sequence Prediction: Class=random positive increments Difficulty=11993 (Worthy challenge)
Remote operating system guess: Windows 2000 RC1 through final release
---- My Linux box (RedHat 7.0, all updates)
TCP Sequence Prediction: Class=random positive increments Difficulty=5472011 (Good luck!)
Remote operating system guess: Linux 2.1.122 - 2.2.14
---- On of work's retired NT4 servers
TCP Sequence Prediction: Class=trivial time dependency Difficulty=4 (Trivial joke)
Remote operating system guess: Windows NT4 / Win95 / Win98
Our WatchGuard firewall returns a dificulty of 9999999.
---
Yes, it's incredibly difficult to generate random numbers. Isn't it impossible? Consider this. ALL events can theoretically be traced back to a specific cause. If you ask a human to give a random number between 1 and 10, the outcome is a result of many psychological factors that predisposed that person to respond with a certain number. Likewise, if you were to go back to the beginning of the universe, and move a few molecules, you'd change the outcome. Therefore, how can anything be truly random. We can have unexpected outcomes, but if you look at the big picture, you can trace results back to causes.
So, to put this on topic, in reference to your second point... it's difficult to generate random numbers - especially on computers. :-) However, we CAN generate psuedo-random numbers. *chuckle*
WINS is TCP-IP based. Moron.
I'm kind of curious what kind of behavior trying to exploit the ISN would show. I mean the best I could think is if one were to simply sniff packets. This isn't very in depth in terms of how ISN generation is done if it is not truly random. I know with attacks such as syn floods there were semi-obvious patterns that revealed what they were going after.
.--bagel--.---------------.
| aim: | bagel is back |
| icq: | 158450 |
( o ) one could say I'm rather baked
I think he was talking about alt.2600. Notice the term "posted"? Oh, that's right, people don't know what USENET is nowadays. It's for the best, really.
But, for the purpose of cryptography, what's important is perspective.
That is, from any given perspective (ie: the user which is trying to predict the next number in a sequence), if the next number cannot be determined (because information which led to that number is unavailable, such as seed generated from keyboard interrupts), the data can be considered truly random.
I mean - technically nothing can ever be absolute (we can't be sure 1+1==2; we've just observed it throughout all of recorded history) so long as time is not infinite (which is also difficult to prove ;). So, if we are going to round up probabilities to absolutes, randomness is best considered from a specific perspective (in which case we can say, for someone, "this data is truly random").
--
All men are great
before declaring war
A government is a body of people notably ungoverned - AC
Exactly! please moderate the parent of this post UP. I get tired of these "recycled" stories. Especially when they are billed as being something new and amazing. Operating systems, including Linux and Windows, now randomize their initial sequence numbers. Linux uses an entropy pool and some nice cryptographic whitening so not only is predicting sequence numbers "theoretical" with today's computing resources, it is "theoretical" with infinite computing resources.
I'm sorry for you, but they might be talking about another kind of attack. Stay tuned to bugtraq for more info.
I work in the security field. People do stuff like this all the time. Gaurdent wanted some attention. The hole was first noticed by none other than Robert Tappan Morris in like 1988 or something. Its first known actual use was by Kevin Mitnick to break into Tsutomou Shimommomomruromomrura's computer.
Kspett
Kevin "Cash Money" Spett
Ignore your rights and they go away.
I thought it was interesting to see that someone actually used the word "cracker" rather than "hacker" in a piece of semi-mainstream journalism.
Two questions - 1) if this "problem" has been around since the mid-80's why has it never been exploited?
Because it's been fixed for quite a while in most OSes. There are still some exceptionally stupid OSes that are vulnerable to it, but nobody who knows beans about security uses them.
-
Here is my plan...I am going to start a security company and point out problems that everyone already knew about (And professors at half decent schools have pointed out in lectures)...using the media for publicity. Then we can watch every site gobble up a story on how our company cracked it.
is here.
sulli
RTFJ.
Like the article stated, this is as old as the hills. I think all of the major O/S` have some kind of patch that improves the randomness (NT 4.0) or it has been fixed in the kernel for a while (FreeBSD) So as usual, if you haven`t been keeping up to date, you are at risk
How does this get legitamized as a front page story? This is the real problem, posts about old security news make the front page, while links to projects to clone humans don't make it.
I want to delete my account but Slashdot doesn't allow it.
Is it me or does it seem like there are many more advertisements disguised as articles. They feature predominantly a re-release of some non-news that's years old by some guy who happens to run a company in the field related to the particular non-news. Seems like I see alot of this from security companies mostly some 'drastic new flaw in IP' and guess what, the CEO featured in the article has a magic panecea he'll sell you to make the non-issue go away. *sigh*
-- Greg
Slashdot, would a spell-checker for posting be too much to ask? It's not rocket science!
let's all switch to UDP (a better protocol IMO)
--
Je t'aime Stéphanie
" HotBits [brought to you by John Walker] is an Internet resource that brings genuine random numbers, generated by a process fundamentally governed by the inherent uncertainty in the quantum mechanical laws of nature, directly to your computer in a variety of forms."
... when nmap has been testing for it for years.
Guardent is trying to garner publicity by 'announcing' a known vulnerability that has been, for the most part, cmpletely addressed!
Way to go guys! Before, I didn't who you were. Now I know you're a complete bunch of retarded chimpanzees!
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
"Guardent officials alerted CERT and the affected vendors to the problem before making it public."
Which vendors have the insecure stacks?
Maybe this is an early warning of another Microsoft-only problem being referred to as an Internet problem, the way that the various Outlook buffer-overflow exploits were referred to as "e-mail viruses" by the media-at-large rather than "piss-poor programming".
If Microsoft's Quality Assurance department fell over in the woods, would it make a sound?
1) if this "problem" has been around since the mid-80's why has it never been exploited?
It has been... Mitnick used it, in fact, to get rootshell via rshd, which does authentication via ip adressing, which you can spoof using the TCP sequence attack.
Kspett
Kevin "Cash Money" Spett
Ignore your rights and they go away.
I was using 2600 (as opposed to other sites like l0pht or what have you) as a tool to indicate the cluelessness of the writer of the article.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
When backhoes are outlawed, only outlaws will have backhoes.
Or something. Nevermind.
"I have nearly cornered the market on hotdog buns -- once I have, I'll have those scurvy Discordians by the balls."
"This is extremely difficult to do. It's a theoretical attack," said security expert Steve Gibson, of Gibson Research Corp. in Laguna Hills, Calif. "It's weird that they're talking about something like this. It's as old as the hills." Er... Isn't this how Kevin Mitnick broke into Shimomura's system in San Diego? IIRC, he spoofed the sequence between a workstation and a Xterminal.
--
"I have also mastered pomposity, even if I do say so myself." -Kryten
--
"I have also mastered pomposity, even if I do say so myself." -Kryten
If you read the article carefully, it says that this could be used to exploit TCP stacks that use a POOR or PREDICTABLE random number generator to generate the ISN. It also says that because this has been known for so long, there are questions about if there are any TCP stacks around that are exploitable.
My guess would be that someone out there found a particular implementation that had this problem and from there, started asking questions about if the problem exists in other implementations.
If the TCP protocol standard specifies that the ISN needs to be 'random', or at least a good psudorandom, than this is a failure of the implementation if it does not follow that spec, NOT a statement that 'TCP', as a protocol, has a security hole.
It's easy to prove that something can't be done. Just assume that it can be done, and show that this assumption leads to a contradiction.
It doesn't allow you to completely hijack a TCP/IP conversation, just to impersonate a particular user. For one message. Because if the server sends a reply to that message and you can't predict how many bytes it's sending, then the ISN will be messed up again. Because you still don't get the return packets.
Come on people, news from this decade (or at least the last one) would be really great.
I am disrespectful to dirt! Can you see that I am serious?!
A bit of digging found the tool HUNT which exploits the problem.
Never play leapfrog with a unicorn. Or a juggernaut.
I just read this on ZDNet and about 20 posts explaining how old this is. we know Guardent is just looking for fame! Waste of time I say.
What security holes lurk in SMB, for example?
SMB is a security hole!
--
RFC1948 which is 5 years old described this problem and how to solve it.
Sig is taking a break!
And in other news, the Berlin Wall has come down! WW II ended! These guys are only about 15 YEARS late on this discovery. Must have been really hard work reading those old papers about the topic.
Poor implementation of randomized ISN's. This is a vulnurability that Microsoft was suceptible to in the initial releases of NT. It requires a good randomization algorithm in order to minimize the vulnirability of TCP/IP, which is something that has been known for quite some time.
An update: http://ds9a.nl/pub/ack-attack.txt shows a possible hole which was posted on bugtraq last night.
Factors
a) the machine you are running
b) the algorithm you are running
c) said alg. musn't be entropic(run out of 'stuff')
If I had more time to futz(or mebbe i did ;), I would come up with a Mandelbrot 'random' generator, because it is computationally intensive, and not predictable. To keep the first two from being a factor, you run the generator during off cycles, when nothing is being sent. The last factor is whether or not the generator will deplete numbers(or repeat). By using mandelbrots, you can use all kinds of data to generate, such as TOD, date, last # of packets and length, yadda, and unless they are running the same data as you, they can't sequence it.
This mind intentionally left blank.
The KKK a bunch of sheetheads? You decide!
when i read this, the fortune at the bottom of the page was also a quote from bruce perens.
you're such a karma whore, bruce. :)
--
It has been exploited. More than once.
2.) How hard can it possibly be to generate a random number, even for a simple OS installed in a router?
It's a lot harder than most people think, but not so hard that it can't be done. There are a lot of ways to screw up, and people being lazy, don't usually do the work needed to create an unguessable (secure) random number. For example, basing a number on the time doesn't work (too easy to guess), and basing it soley on the last state doesn't work (every client sees the random number) See The Yarrow paper for a description of some of the other things people have done wrong.
http://members.nbci.com/forcemajeure/download/m6_n oise.pdf
The idea is the same as the particle decay, except in this case a backward biased transistor is used, which will block most electrons, but some will have enough thermal energy to 'jump the gap'(conduct), which is brownian motion. You could just have easily use a reverse biased diode(hook up cathode(striped) to +, anode to gnd.
Normally you wouldn't care if these are reverse biased, because the leakage current is too small, and 'random'. They sometimes are used as a temperature 'sensor', because the warmer they get, the more likely electrons jump.
This mind intentionally left blank.
The KKK a bunch of sheetheads? You decide!
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
OK, so there is a random number known only by either end of a TCP session. If the number is not random, then a hacker could guess the number and spoof packets.
Two questions - 1) if this "problem" has been around since the mid-80's why has it never been exploited?
2) How hard can it possibly be to generate a random number, even for a simple OS installed in a router?
This problem to me seems to be a non-problem, but you networking gurus might have a different story.
No, Thursday's out. How about never - is never good for you?
It's not that this problem is new, or potentially really bad on it's own, but it's that they're afraid that as soon as hackers post tools to 2600, all the script kiddies will go out and exploit it, because currently, nobody's hitting this one, because it's too difficult for most people to grasp.
Or maybe it's a vieled attempt by Microsoft to discredit TCP/IP so they can get the whole world to switch back to NetBEUI and WINS.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
It goes without saying that TCP is one of the fundamental protocols billions of dollars of internet infrastructure and other businesses rely on. If it could happen to TCP, then which other protocols are vulnerable to similar problems? What security holes lurk in SMB, for example? Will we ever know?
Even Linux 2.1.53 had a massive TCP/IP-stack hole, so we know we're not invulnerable. This isn't just a problem for others.
Ok I submitted a much clearer picture of this story, but apparently that didn't get posted.
Anyway, this company has "discovered" that if ( a big if) you can predict the ISN of a remote host you can (gasp!) hijack/spoof a TCP connection. Gee, I think I heard about that in 1985. This was on ZDnet this morning and they have since changed their story to reveal just how old and well known this really is.
I know there was 1989 paper on this exact subject by AT+T, try searching for it.
Also, try using nmap on any host today. See how it says "truly random" for many many of them (including linux), that is why this vulnerability means nothing in practice. Practically every OS under the sun has good enough random ISN's that no one is going to correctly guess them.
This is just another security firm trying to get some contracts by issuing a big scary press release.
Please.
like the article itself says, this isn't exactly shocking news...the framers of tcp knew about it and most security books make mention of it somewhere (the o'reilly firewalling books leap immediately to mind)
-dk
-dk
Dream with the feathers of angels stuffed beneath your head.