Old software weakening Net's backbone, survey says
DNS servers, which translate domain names such as "yoursite.com" into IP addresses, underpin the workings of the Internet. In its survey, Internet performance company The Measurement Factory found that the BIND software used for domain-name resolution is out-of-date on a fifth of DNS servers.
DNS servers that run versions of BIND earlier than version 9 are "opening the door" to pharming attacks--a kind of phishing attempt--through DNS cache poisoning, the company said in its report.
DNS servers--an Achilles' heel
DNS cache poisoning involves hacking into DNS servers and replacing the numeric IP addresses of legitimate Web sites with those of malicious sites. Internet users are then redirected to fake Web pages where they may be asked for information such as bank account details or unwittingly have spyware installed on their PCs.
Thomas Kristensen, the chief technical officer at security company Secunia, said it was likely that 20 percent of DNS servers were running out-of-date software, as the survey claimed, but he downplayed the risk of vulnerabilities being exploited.
How does DNS get poisoned?
There are a few steps to go through before a DNS server starts redirecting Web surfers to bogus sites.
Most people's PCs access a DNS server at an Internet service provider or within a company to map text-based Internet addresses to actual IP addresses. One DNS server can be used by thousands of Internet users.
For performance reasons, DNS servers cache the returned data, so that it takes less time to respond to the next request. When a DNS cache is poisoned, it affects all future lookups of the affected domain, for everyone who uses that particular DNS server.
To poison a DNS server:
• First, the target machine has to be tricked into querying a malicious DNS server set up by the attacker. This can be done, for example, by sending an e-mail message to a nonexistent user at the target ISP. Another way is to send an e-mail with an externally hosted image to an actual user.
• The target DNS server will then query the attacker's DNS server. In the DNS reply, the scammer includes extra data that will poison the victim's DNS cache. The extra information can be a malicious URL or even an entire domain space, such as .com.
• If the target DNS server is not configured properly, it will accept the new numerical IP listing and delete the proper entry.
• Once this has occurred, any queries sent to the DNS server for the affected URLs will be redirected to the replacement IP addresses set by the attacker. If a domain space is poisoned, all queries ending in that domain will be redirected.
Source: SANS Internet Storm Center, CNET News.com
"It should be noted that the 8.x and 4.x versions (of BIND) aren't vulnerable as such, but they were designed in a manner which makes them unsuitable for use as forwarders in specific DNS server setups. If these servers are used in a setup where they are used as forwarders, then it is possible to conduct cache poisoning attacks against them," Kristensen said.
Kristensen added that the Internet Systems Consortium, the group behind BIND, strongly recommends against using 4.X and 8.X versions of the software as forwarders.
A DNS server stores the numerical addresses of legitimate Web sites in a cache. A DNS forwarder will send queries on to another name server, if it does not have the necessary information to resolve these requests itself.
This process is known as "recursive name service," as the DNS server will push its request up the hierarchy of DNS servers until it reaches one that can resolve it.
The Measurement Factory surveyed 1.3 million DNS servers, and found that more than three-quarters of them allow recursive name service for "arbitrary queriers," or unspecified machines, rather than just for trusted users. This could open a name server up to malicious attacks, according to the report.
In theory, once a malicious hacker has compromised one DNS server, the recursive name service could be used to force other DNS servers to contact the compromised server to resolve a request. Over time, this would allow the hacker to poison the caches of a large number of DNS servers, via the cache of one compromised machine.
Recursive name services should only be enabled on a DNS server for a restricted list of trusted requestors, according to Inblox, the infrastructure developer that commissioned the survey.
"It is not a good idea to allow arbitrary people to do recursive queries as it makes cache poisoning and denial-of-service attacks much more likely," Kristensen agreed. "Generally, recursive queries should only be allowed from specific IP addresses."
Internet service providers should only provide DNS services to their own customers, Kristensen suggested. "Generally, all users who connect to the Internet using other connections than leased lines and business-class xDSL lines are dynamically assigned IP addresses, gateways and DNS servers each time they log on," he said.
Malicious hackers who wanted to compromise DNS servers through the recursive name services feature would need to know how various DNS servers are linked together. They could do this by requesting a zone transfer--a query that asks a name server which other servers are contained within its "zone."
The Measurement Factory's survey found that more than 40 percent of DNS servers also allow zone transfers from arbitrary queriers. The report said this exposes a name server to denial-of-service attacks and gives attackers information about internal networks.
Secunia's Kristensen agreed this was a bad idea. "Opening a name server for zone transfers does very often expose an excessive amount of information about 'secret' hosts, internal hosts, gateway configuration and much more. This kind of information may prove very useful for a malicious person wishing to conduct an attack," he said.
Zone transfers should only be allowed by internally controlled secondary name servers, Kristensen added.
Inblox has advised IT professionals to take these six steps to mitigate against DNS vulnerabilities:
• If possible, split external name servers into authoritative name servers and forwarders.
• On external authoritative name servers, disable recursion. On forwarders, allow only queries from your internal address space.
• If you can't split your authoritative name servers and forwarders, restrict recursion as much as possible. Only allow recursive queries if they come from your internal address space.
• Use hardened, secure appliances instead of systems based on general-purpose servers and operating software applications.
• Make sure you run the latest version of your domain name server software.
• Filter traffic to and from your external name servers. Using either firewall- or router-based filters, ensure that only authorized traffic is allowed between your name servers and the Internet.
Tom Espiner of ZDNet UK reported from London.