CSO Newsletters
What is a CSO?

Tag this story:

delicious

digg

reddit

Home > Archives > February 2007 >

DNS: Definitely Not Safe?

New attacks on the Internet’s domain name system keep CISOs guessing. Here’s what you can do about it.

By Erik Sherman

E-mail this article  |  Printer friendly



Related

Desire Network Safety?

(Not So) Eminent Domains

A recent study commissioned by Infoblox and performed by The Measurement Factory suggests that incorrectly configured DNS servers present a security problem waiting to happen.

• Estimated number of DNS servers: 9 million
• DNS servers that allow recursive name services that relay requests to other name servers: more than 50%
• Vulnerability opened by recursive operations: pharming attacks
• DNS servers that allow zone transfers, which enable ­duplication of DNS data: 29%
• Vulnerability opened by zone transfers: denial of service attacks
• DNS servers running BIND 8, an older, less secure and less reliable version of DNS software in 2006: 15%
• Those running BIND 8 in 2005: 20%

When it comes to the Web's domain name system (DNS), many otherwise vigilant CSOs heed the adage of leaving well enough alone. It's understandable, as DNS has for years reliably allowed people to use domain names (such as www.csoonline.com) with their Web browsers rather than having to remember remarkably non-mnemonic IP addresses (such as 64.28.79.93).

Unfortunately, for all its success, DNS is one area in which what you don't know can hurt you—badly. Despite well-publicized attacks on domain name servers in 2000 and 2001, evidence suggests that many companies simply have not taken the steps necessary to protect this vital part of their networks. Experts differ on just how much danger companies generally face. However, they seem to agree that, depending on the circumstances and the company, the results could include electronic attacks and unknowingly providing confidential information to competitors. Some companies aren't just leaving the back door unlocked—they're taking out the hinge pins and removing the door entirely.

"There is a lack of appreciation of just how damned vulnerable DNS is," says Lloyd Hession, CSO for BT Radianz. Indeed, the U.S. Department of Homeland Security's Computer Emergency Readiness Team (CERT) has recently reported a rise in distributed denial-of-service (DDoS) attacks using DNS. No matter how safe DNS may seem, companies need to stay alert. Here's a quick roundup of DNS vulnerabilities and attack methods CISOs should understand.

Open to Misuse

What makes DNS such a vulnerable part of the Internet is the range of exploits it makes possible. DDoS attacks are the best known because they were the basis of some prominent attacks a few years ago. DNS servers can be the targets of these attacks, but—and this is less widely known—hackers can use DNS servers to perpetrate a DDoS attack on a third party, essentially amplifying the volume of data hitting the target system by upwards of 4,000 percent.

On one hand, says Marty Lindner, senior member of the technical staff at the Carnegie-Mellon University CERT/CC, DDoS can be executed by bombarding a DNS server to block real traffic from getting in and effectively keeping those users off the Internet. Perpetrators can also flip the tactic, creating spoofed requests to a DNS server that supports recursion. Recursion is the method by which a name server hunts down the IP address of an unfamiliar domain name by working down trees of name servers that provide authoritative information on given parts of the Internet. The original name server receives one packet of information after another that each provide the equivalent of directions to reach the destination, and passes them all on to the requester. When the initial request is spoofed with the address of the hacker's target, all that data goes whistling back to the target. "It doesn't take more than 10 or 20 name servers to mount a denial-of-service attack against another target," says Cricket Liu, vice president of architecture at network appliance vendor Infoblox and coauthor of the book DNS and BIND.

Recursion is just one way to have a name server send bucketfuls of data to a target. Another is zone transfer, part of the DNS protocol that enables any name server to replicate its zone data to other name servers. One request can create a response with all the information for that name server's zone: computer names, IP addresses and possibly other information that describes the type of hardware and the version of operating system. According to Liu, with a big enough zone, the transfer can take 15 minutes or longer to complete. In addition to creating bandwidth-choking amounts of data, these zone transfers use the Transmission Control Protocol (TCP) rather than the lower-overhead but more easily spoofed User Datagram Protocol (UDP) commonly favored by other Net-based services. That makes zone transfer more resource intensive, putting a greater strain on both the generating name servers and the receiving machine.

Zone transfer also represents a disturbing amount of detail that a hacker can legally glean from a target without probing. Furthermore, this information can provide significant clues to the activity of a company and where it devotes its strategic IT resources—a boon for rivals seeking competitive intelligence.

Because most IT departments see DNS as reliable, they often barely monitor their name servers. The DNS servers sometimes don't run through the firewall, according to CERT/CC's Lindner, making them a perfect way for someone who has broken into a network to tunnel sensitive data out by piggybacking it on DNS packets that no one will notice. "[What hacker] cares if it takes a week to get the data out?" asks Lindner.

Some data takes significantly less time to obtain. Dan Kaminsky, director of penetration testing for security consultancy IOActive and longtime DNS critic, notes that because of the way DNS caches data, there is much that someone can pick up using a technique called cache snooping. "If your internal name server is also shared and accessible on the outside world, then I can see if company A is e-mailing company B, how often are people going to Google or Yahoo," he says. Again, it's not necessarily anything that will physically compromise a network, but it's still information you don't want a hacker or competitor to get.

And if DNS runs on a server that also runs other network services, something that Kaminsky has seen at some companies, a compromise of the other services could render the name server vulnerable as well.

Taking Control

Aside from becoming a data sieve, DNS is subject to more subtle attacks via tampering and cache poisoning. By changing the actual lookup data in the DNS cache, an attacker can replace a server's real IP address with one that will lead a user to the attacker's own machine. Until the cache eventually refreshes, users will be misdirected with potentially no clue to what actually happened. Hackers can use this attack to direct traffic away from the website and potentially capture private information from users. This is the tactic known as "pharming" (see "After Phishing? Pharming!").

"It's a hard attack to detect," says Lindner, "because if you're running a big website and all of a sudden no one is coming to your website, you know something's wrong. But if a half dozen name servers have cache poisoning, it's too small [a diversion] and you won't notice it."

There has been talk for years of making DNS bulletproof by adding a public-key cryptography layer through an approach called DNSsec. "DNSsec tries to solve the spoofing problem that SSL has already solved, and the extra round-trip for DNS queries to get the public-key record only adds latency [to data traffic]," says Nate Lawson, a senior researcher at Cryptography Research. Public-key cryptography also requires companies to authenticate themselves to a certificate authority and pay for the use of a certificate, reducing the chance that many will buy in to the system. Finally, according to Kaminsky, a fundamental problem is getting all the root domains to sign up. "Everyone above you in the DNS tree must be signed," he says. "Everyone has to get on board or it doesn't work."

Despite these concerns, DNS isn't the biggest security worry a company can have. ("E-mail's in way more dire straits," Kaminsky says.) Yet it can still cause significant problems, and chances are good that any company has potential problems with at least some of its DNS name servers.

Erik Sherman is a freelance writer based in Massachusetts. Send feedback to csoletters@cxo.com.


Add a Comment:

Your comment will be displayed at the bottom of this page, at the discretion of CSOonline.

* Name:

* Title:

* Corp:

* E-mail:

* Subject:

* Your Comment:

 
* Required fields.

We do not post comments promoting products or services.
Comments are owned by whomever posted them. CSO is not responsible for what they say.
Selected comments may be published in CSO magazine.
We will not sell your personal information.
We do display your name, title, and corporation but not your e-mail address.





Most Recent Responses:

|| ... most of them are just looking for publicity and really have no clue about what they are talking about

that includes this article which is replete with gibberish cut and paste mistakes.

try consulting those who implemented the software or protocols instead of random trolls like effugas when you want sources.

Noone
of
Consequence
Print

There are a lot of technical errors in this article. First, there is a big difference between a RDDOS attack and a DDOS attack is. You call a RDDOS attack a DDOS attack in paragraph 4. Second, attacks on DNS’s recursion functionality have been fixed on all DNS server software packages for years. Plus, your explanation of recursion based attacks is completely wrong. Third, as for zone transfer attacks, how exactly is someone going to exploit them to cause some sort of denial of service? (i.e. zone transfer run on TCP, as such you can’t spoof a server do dump zone data to a host other than your own). Fourth, I know of no organization that does not firewall all external and internals hosts. Fifth, I question the viability of “cache snooping” tactic. There is no viable way to dump a DNS server’s cache without first hacking into the server; which at that point, the hacker is better off doing far more malicious things. Sixth, the attack you describe as a pharming attack is that same as the recursion attack you described earlier. At least this time you describe the attack correctly.

Please, please, please do more research into your articles before publishing. Also, don’t believe every "security expert" you run across, most of them are just looking for publicity and really have no clue about what they are talking about.

Adam Stasiniewicz
System Administrator
Harley-Davidson Motor Company
Email
Print

Ads by TechWordsSee Your Link Here

Sponsored Links:

May 2006 cover

Subscribe to CSO Magazine

Free Subscription
Our print publication is free to qualified readers in the United States. United States residents can apply online.

Paid Subscription
If you live outside the United States or do not qualify for a free subscription click here.

Sponsored content

All White Papers

All Podcasts

Sponsored Podcasts

All Webcasts

All Partner Domains


advertisement