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.

Comments

Not that Theoretical - Mitnick did just this

[Frums]

Unfortunately I do not have my source, but if I remember right Mitnick did a smurf just like this to execute a blind man in the middle attack.

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

Re:Not that Theoretical - Mitnick did just this

[wavelet]

Tsutomu Shimomura's book's webiste, Takedown has some transcripts of the attack.

Interesting read... in 1995...

Basically one of Shimomura's unix boxes had root level .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

It's not meaningless, just very old...

[tqbf]

This problem is old. Even in the context of Cisco routers. Mudge@L0pht testified about basically this exact problem in front of congress a few years ago, and even then it was old hat.

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.

This is out of proportion

[Geoff NoNick]

The article says that this is a potentially huge problem, but the fact of the matter is that it's:
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

Random Numbers

[citizenc]

2) How hard can it possibly be to generate a random number, even for a simple OS installed in a router?

I actually had a rather lengthy argument with my computer sciences teacher about this -- it is impossible to generate a truely random number.

It is kind of like trying to prove something can't be done.

------------
CitizenC

Re:Random Numbers

[Anoriymous Coward]

If you need a random number, go here:

www.fourmilab.ch/hotbits/

The guy has a geiger-muller tube pointed at a radioactive source. The time between detected events is random. Really random.
--
#include "stdio.h"

Re:Random Numbers

[rw2]

I actually had a rather lengthy argument with my computer sciences teacher about this -- it is impossible to generate a truely random number.

I don't know which side of the argument you were on, but whoever said it is "impossible" is really really wrong. It's actually quite trivial.

More importantly, it's rarely useful to argue about the difference between a truly random and a pseudo-random number. This TCP story is one of the vast number where good pseudo-random numbers are plenty adequate.

--

Re:Random Numbers

[pafein]

2) How hard can it possibly be to generate a random number, even for a simple OS installed in a router?

I actually had a rather lengthy argument with my computer sciences teacher about this -- it is impossible to generate a truely random number.

Actually, IIRC, SGI did this using digitized photos of lava lamps as seeds.

It is kind of like trying to prove something can't be done.

Come now. Mathematicians do it all the time.

Re:Random Numbers

[Fatal0E]

I remember reading a long time ago about a couple of programmers who needed a strong encryption routine so they improvised one.

They pointed a web cam at a lava lamp(!). The pictures are the hash source for the random number generator. Their theory was something like, "What could be more random then a Lava Lamp?!" Here's a link to something similar but I won't say it's -the- one I'm talking about since I honestly cant remember where I saw it originally.
"Me Ted"

Re:Random Numbers

[Mihg]

Quoting /usr/src/linux/drivers/char/random.c:

Theory of operation

Computers are very predictable devices. Hence it is extremely hard to produce truly random numbers on a computer --- as opposed to pseudo-random numbers, which can easily generated by using a algorithm. Unfortunately, it is very easy for attackers to guess the sequence of pseudo-random number generators, and for some applications this is not acceptable. So instead, we must try to gather "environmental noise" from the computer's environment, which must be hard for outside attackers to observe, and use that to enerate random numbers. In a Unix environment, this is best done from inside the kernel.

Sources of randomness from the environment include inter-keyboard timings, inter-interrupt timings from some interrupts, and other events which are both (a) non-deterministic and (b) hard for an outside observer to measure. Randomness from these sources are added to an "entropy pool", which is mixed using a CRC-like function. This is not cryptographically strong, but it is adequate assuming the randomness is not chosen maliciously, and it is fast enough that the overhead of doing it on every interrupt is very reasonable. As random bytes are mixed into the entropy pool, the routines keep an estimate of how many bits of randomness have been stored into the random number generator's internal state.

When random bytes are desired, they are obtained by taking the SHA hash of the contents of the "entropy pool". The SHA hash avoids exposing the internal state of the entropy pool. It is believed to be computationally infeasible to derive any useful information about the input of SHA from its output. Even if it is possible to analyze SHA in some clever way, as long as the amount of data returned from the generator is less than the inherent entropy in the pool, the output data is totally unpredictable. For this reason, the routine decreases its internal estimate of how many bits of "true randomness" are contained in the entropy pool as it outputs random numbers.

If this estimate goes to zero, the routine can still generate random numbers; however, an attacker may (at least in theory) be able to infer the future output of the generator from prior outputs. This requires successful cryptanalysis of SHA, which is not believed to be feasible, but there is a remote possibility. Nonetheless, these numbers should be useful for the vast majority of purposes.

So, yes, I have RTFM (RTFS?) in this case (and before this article was ever posted, which should give me bonus points).

The time between the interrupts caused by my keypresses and mouse movements is random. PGP for DOS used this fact directly, however modern operating systems provide their own sources of random bits based on the same principle.

Note that devices that measure radioactive decay can be easily hooked up to the Linux random number generator. :-)

---
The Hotmail addres is my decoy account. I read it approximately once per year.

Re:Random Numbers

[blair1q]

Your CS professor was wrong:

radioactive decay random-number generator
atmospheric noise random-number generator

--Blair
"Nineteen billion bits can't be wrong!"

Re:RFC1948

[Anonymous Coward]

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.

Re:NITROGEN WARNING is similar to TCP/IP warning

[dattaway]

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.

NITROGEN WARNING is similar to TCP/IP warning

[Bruce Perens]

The warning we are now reading about TCP is very similar to this NITROGEN WARNING:

Warning! Scientists have determined that, if you live in the U.S., over 70% of the air you breathe is now NITROGEN. Nitrogen is a colorless, odorless gas that can actually DROWN YOU by excluding oxygen from your environment.

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

Re:NITROGEN WARNING is similar to TCP/IP warning

[fluffhead]

Even more hilarious is the DHMO.org website. A thinly veiled crack at the MSDS (Material Safety Data Sheet) phenomenon... even though I'm an ex-environmental lawyer I found it funny.

#include "disclaim.h"
"All the best people in life seem to like LINUX." - Steve Wozniak

Re:"Old as the Hills"

[SEWilco]

I've discovered that when a backhoe cuts the wire connecting me to my ISP, the network suddenly fails. Nothing I do to the network interface seems to fix the problem. I've found documentation that this problem is as old as the hills, yet nothing has been done about it. I thought I'd better announce this in case another backhoe is built.

Re:Which other protocols *also* have holes?

[johnnyb]

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/

guessing a tcp sequence isnt *THAT* hard...

[b0r1s]

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.

Re:Looks like a pretty standard case to me.

[Cramer]

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.

simlar security hole in *every* os

[peterjm]

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

Fun with NMAP TCP Sequence Prediction.

[e_n_d_o]

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.

---

Randomness does not exist.

[Gendou]

2) How hard can it possibly be to generate a random number, even for a simple OS installed in a router?

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*

Re:Randomness does not exist.

[hawk]

> Consider this. ALL events can theoretically be traced back
> to a specific cause.

Pardon???? That's true in the newtonian universe, but not at lower levels.

At the quantum level, things are fundamentally random, and the "hidden
numbers theory" has long fallen out of fashion.

I don't know enough about thermal processes, but radioactive decay is, in thoery,purely stochastic--there are no causal variables and deviations from the mean number of decay evnts *must* be purely random.

hawk, once a physcist

Version without big-ass ad

[sulli]

is here.

Looks like a pretty standard case to me.

[Bonker]

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!

Re:Is this really a problem?

[kspett]

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

Re:"Old as the Hills"

[wunderhorn1]

but remember the quote from l0pht's old website (which isn't up anymore, so I'm doing this from memory):

Microsoft: That vulnerability is completely theoretical
l0pht: Making the theoretical practical since 19XX

RFC1948

[johnburton]

RFC1948 which is 5 years old described this problem and how to solve it.

Which other protocols *also* have holes?

[alewando]

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.

FRAUD

[Anonymous Coward]

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.