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
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).
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.
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
It is kind of like trying to prove something can't be done.
------------
CitizenC
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
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.)
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.
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
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)
#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
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
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.
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.
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.
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*
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
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.
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
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!
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.
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.
A bit of digging found the tool HUNT which exploits the problem.
Never play leapfrog with a unicorn. Or a juggernaut.
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.
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.