Requires Free Membership to View
SearchSecurity.com members gain immediate and unlimited access to breaking industry news, virus alerts, new hacker threats, highly focused security newsletters, and more -- all at no cost. Join me on SearchSecurity.com today!
Michael S. Mimoso, Editorial Director
Take DNS cache poisoning, for example. Attackers use this technique to trick a DNS server into believing it has received authentic information when, in reality, it has not. In fact, it's because DNS responses are not usually cryptographically signed that there are so many attack possibilities.
As the use of DNS outgrows its original purpose -- it's being used with an increasing myriad of Internet-connected devices from smartphones to kitchen appliances -- it is becoming more important that both DNS queries and responses are better protected. Yet securing DNS is proving difficult, as any changes have to be backwards-compatible with older systems and yet still scale to the size of the Internet. This and a lack of cooperation between major Internet players are why initiatives to improve the security of DNS, such as the Domain Name System Security Extensions (DNSSEC), have yet to be widely adopted (DNSSEC modifies DNS to add support for cryptographically signed responses).
Another approach to help validate DNS results is Forward Confirmed Reverse DNS (FCrDNS). FCrDNS checks that an IP address has both forward and reverse DNS entries that match each other. These entries are used to authenticate a valid relationship between the owner of a domain name and the owner of the network that has been given an IP address. While weak, this authentication is strong enough that it can be used for whitelisting purposes. Because of a statistical correlation between machines that send spam and machines that fail FCrDNS check, spammers and phishers usually can't bypass this verification when they use compromised computers to forge the domains.
Even with encryption, a DNS server can become compromised by a virus or a disgruntled employee who could redirect the server's IP addresses to a malicious address with a long time-to-live (TTL) value. Every DNS server that cached the bad IP data would have to be manually purged, as a TTL can be set for as long as 68 years!
Then there's the problem of typos. How often have you misspelled the address of the website you want to visit but still ended up at a website? For example, paypal.com and paypa1.com are different domain names, yet users may be unable to distinguish between them, particularly if their typeface doesn't clearly differentiate the letter l and the number 1. This problem is even more serious in systems that support internationalized domain names, since many characters that are different, from the point of view of ISO 10646, appear identical on a typical computer screen. This vulnerability is often exploited in phishing.
As with most protocols used on the Internet, it is becoming imperative in the interest of security and privacy to prevent the disclosure of dialogues between the intended client and server. If a large number of popular name servers were to adopt strong cryptography, many attacks on DNS would be rendered useless. Even so, DNS would still be a long way off from the point where it is secure enough to be part of a cryptographic service.
More information:
This was first published in November 2008