Don't Blame TCP/IP

A potentially lethal DNS cache-poisoning flaw. A man-in-the-middle Internet routing attack (PDF). And a mysterious denial-of-service attack using the Transmission Control Protocol (TCP): These recently exposed threats to the Internet are potentially lethal, but do they signal a security meltdown of the underlying Transmission Control Protocol/Internet Protocol (TCP/IP) protocols?

On the surface, it appears that the 30-something TCP/IP protocol stack may finally be showing its age, at least when it comes to security. Revelations of new possible attack risks to the Internet's infrastructure have basically refocused attention on the TCP/IP protocols and, oddly enough, at a time when attackers are mostly setting their sights on application-layer hacks.

But security experts say these attacks don't demonstrate TCP/IP flaws, but instead the vulnerabilities in applications and a lack of secure endpoint communications. Besides, TCP/IP wasn't built with security in mind, they argue.

Dan Kaminsky, who discovered the DNS cache poisoning flaw, says TCP/IP isn't broken, but what makes these TCP/IP-type attacks so significant is their potential scope. "The point is not that TCP/IP is vulnerable. In fact, of all the code out there, TCP/IP doesn't even register anymore as a source of real [security] issues [today]...between browser bugs on the client and endemic cross-site scripting and SQL injection flaws on the server," Kaminsky says. "The point is that when TCP/IP has an issue, so much else is affected."

Kaminsky blames weak endpoint and application security for putting TCP/IP at risk. "In both the BGP [man-in-the-middle] and DNS cases, the impact is so much greater than it has any right to be. It shouldn't matter that a bad guy can read or reroute your traffic; applications should be encrypting and authenticating everything to their intended endpoints," he says.

The DNS cache poisoning flaw Kaminsky found, for example, redirects victims to a malicious Website without their knowing, and the man-in-the middle attack exploits functions of the Border Gateway Protocol (BGP) to reroute Internet traffic remotely.

Meanwhile, ISPs apparently are worried about the risk of these infrastructure-based attacks: They rank DNS cache poisoning as the No. 2 most significant threat during the next 12 months -- just behind botnets and followed by BGP/route hijacking and DDoS attacks on infrastructure services such as VoIP and DNS, according to a report due for release Tuesday by Arbor Networks.

The three newly discovered TCP/IP threats are really not new, however. The DNS cache poisoning and BGP routing attack disclosures exploit flaws that have been known about for years: "The [new] DNS and BGP attacks are better-engineered versions of the sorts of threats we've known about for a long time," says Steven Bellovin, professor of computer science at Columbia University and one of the fathers of the network firewall. Bellovin says he and another researcher first discovered the underlying flaw in BGP 20 years ago, and he wrote about DNS "contamination" in 1990.

These attacks are basically faster. "The speed has changed, not the threats," says Craig Labovitz, chief scientist for Arbor Networks. "The law of physics hasn't changed -- there's just more awareness that you can do the attacks and do them better."

It took Kaminsky only tens of seconds to poison the DNS cache in his research, for example, while it used to take anywhere from tens of minutes to hours to do so, Labovitz notes.

Details of the TCP DoS vulnerability that executes a denial-of-service attack against broadband Internet connections have not yet been disclosed, but the researchers who found it say it's basically a function of vulnerabilities that have been around for some time. "This doesn't mean we're the first to see them," says Robert E. Lee, chief security office of Outpost24, and one of the researchers who discovered the attack.

The flaw lets an attacker take down computers by sending out just a few malicious TCP packets. "The difference between our research and what we've seen others do...they've rarely taken it to the next step, [showing] when you use this attack against an application, what are the consequences?" hints Jack Lewis, a senior researcher with Outpost24, who discovered the attack. "We try to make test cases."

NEXT: How to improve IP instrastructure security So what can be done to secure the IP infrastructure from these and future attacks? "It's political and about business as much as it is technical," Arbor's Labovitz says.

There are several security protocols aimed at improving TCP/IP security, including DNSSec for protecting DNS servers, a few proposals for securing BGP, and IPSec for encrypting communications between routers. But none have been widely deployed.

Encrypting routing and applications that ride on the Net is one option, but encryption raises the thorny issue of who owns the public key infrastructure "root," as well as performance and investment issues, for instance. "No wants to go to a monolithic policy" on encryption or security, Bellovin says. "We know more or less how to secure routing. Any conceivable fix is going to run up against any of the same issues for adopting any of the secure solutions for routing. Can you afford [encryption] key computations? Who is the root for PKI?"

A better solution would be to add encryption only where it's necessary, as with BGP and DNS, he says. And enterprises and vendors must spend more time eliminating buggy code, he says. "The real issue is the apps. Make sure your Web server is secure, and your browsers are secured to the latest patch level. "

Tony Kapela, a researcher who demonstrated the routing attack at DefCon, says it may be time to resurrect IPSec. "IPsec was supposed to be host-to-host [router-to-router], but it didn't happen. This might be yet another reeason to do what we tried to do 10 years ago [with IPSec]," says Kapela, who is network director and partner for 5 Nines Data. "It's more important than ever to put money into efficient encryption."

And blaming TCP/IP for not doing what it wasn't intended to do is short-sighted, says Kaminsky, who is director of penetration testing for IOActive. "Yes, we had to fix DNS. Maybe someday we can figure out how to fix BGP. But these are at best fingers in the dike," he says. "We must as an industry secure our endpoints. It's 2008: Where's secure email?

Meanwhile, there will be more infrastructure risks exposed by researchers, he says. "We'll definitely find more infrastructure vulnerabilities. The reality is, they expose so much low-hanging fruit that was previously unreachable to an attacker, such as broken auto-updaters that do nothing but go to the insecure Internet and ask, 'Hello Internet! Do you have any arbitrary code you'd like me to install?' Who needs buffer overflows when you can intercept that request?" Kaminsky says.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message