News

DNS Still Less than Secure

Exploits for a serious cache-poisoning vulnerability discovered in the Domain Name System (DNS) last year have begun to appear in the wild, and they have made security researcher Dan Kaminsky a believer in DNS Security Extensions (DNSSEC).

"I've never been a DNSSEC supporter," Kaminsky said today at the Black Hat Federal security conference being held in Arlington, Va. "At best, I've been neutral on the technology."

Kaminsky, director of penetration testing at IOActive Inc., last year discovered the vulnerability in the DNS that underpins the Internet and helped to engineer the release of a patch for it. The patch, which introduced more port randomization into DNS servers, was merely a quick fix and Kaminsky said he has come to the conclusion that no security technology except DNSSEC can scale well enough to fix the problem.

"DNS scales like absolutely nothing else," he said. That is why the technology has been so long-lived and ubiquitous. "DNS is the only way to scale systems across organizational boundaries." And that means it extends its unsecurity to everything it touches -- which is nearly everything on the Internet.

The problem with DNSSEC is that it is difficult to deploy and manage, and it has been adopted only slowly and reluctantly. The federal government is leading the way by deploying it in the top-level .gov domain this year, but the General Services Administration, which is spearheading the move, said earlier this month that implementation will be delayed by one month. The .gov registry, the registrar and the .gov DNS servers were supposed to have digitally signed by the end of January, but GSA officials said it had identified an additional feature that is needed and that they expect to deploy DNSSEC by the end of February.

"We have got to make DNSSEC deployable," Kaminsky said. "It has to be so much simpler than it is today."

DNS is a hierarchical system that translates written domain names such as those in URLs and e-mail addresses into IP addresses. The vulnerability discovered by Kaminsky could allow cached data in DNS name servers to be poisoned and Web requests to be misdirected, sending users to unknown Web sites. Web poisoning exploits already were known, but because the new vulnerability is in the basic design of the protocol itself it is potentially more dangerous that previous problems.

The vulnerability involves a weakness in the transaction ID used in DNS queries. Currently, replies to a DNS query have to contain the proper transaction ID, which is chosen randomly from 65,000 values. "For undisclosed reasons, 65,000 is just not enough," Kaminsky said when the vulnerability was announced. "We needed more randomization."

That was provided with the patch released in July 2008. Adoption of the patch has been good, but not good enough. Kaminsky said 66 percent of name servers had been patched after one month, much better than the average of 50 percent in a year for most patches. Today, an estimated 75 percent of name servers have been patched, but that means that 25 percent still could be vulnerable.

And the port randomization patch was never meant to be a permanent fix. "We have bought you as much time as possible," Kaminsky said when it was released.

He said today that monitoring by a team from Georgia Tech University had uncovered evidence of exploits for the vulnerability, with occasional brief spikes in misdirected queries.

"Detecting poisoning is difficult," Kaminsky said. "The evidence is written in invisible ink," and the poisoners are being stealthy. "What seems to be happening is that there is testing going on."

Indications are that 1 to 3 percent of unpatched name servers have been poisoned. That is a small percentage, but there currently are an estimated 11.9 million name servers facing the Internet, and nearly 3 million of them probably are not patched. That means that as many as 89,250 servers could have been quietly poisoned.

DNSSEC is a security protocol that allows DNS queries and answers to be digitally signed and authenticated. With DNSSEC, answers to requests are digitally signed to protect clients from forged DNS data. The protocol provides authentication of the origin of DNS data, data integrity, and authenticated denial of existence for an address that cannot be found. To date, only a statistically insignificant number of zones are believed to be using DNSSEC.

Some appliances are available that automate DNSSEC processes so that manual signing and updating are not needed. Servers generate key material and sign automatically so that administrators do not have to manage the process. However, it still is not simple enough, Kaminsky said.

"Substantial work needs to be done with DNSSEC," he said. "But I think it can be done. There is no reason to think it is impossible."

About the Author

William Jackson is the senior writer for Government Computer News (GCN.com).

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube