DNS cache poisoning
It was of course inevitable that once Dan Geer found a vulnerability in DNS, someone else would find it too, even if Dan asked people not to publicize it. It was also inevitable that someone would quickly write a metasploit plugin for it. What amazes me is the fact that despite all the fuss over this, everyone who was security conscious should have had this problem fixed years ago. Yes, I know it was only “discovered” recently, but what people are failing to highlight is that to exploit this against a DNS server, you have to allow recursive queries from third parties. I’ve been telling my clients for years to turn that off (the ones that had it on that is). This falls under the old security rule of “if you don’t need it, turn it off”, which is perhaps the single most important, and yet often ignored, security rule there is.
Since cache poisoning became a worry it has been well known that leaving recursive queries on was allowing an attacker an avenue to force your DNS server to make specific and known queries. This is a necessary step in almost any poisoning attack. In 2007, a study found that about half the DNS servers on the net still allowed recursive queries. Even after repeated warnings and previous DNS vulnerabilities, you would think that most people would have disabled recursive queries, but it doesn’t look like that’s the case. (Furthermore, the response has universally been to patch, rather than to turn off recursive queries). The solution to this and almost all other cache poisoning attacks is very simple:
If you don’t use it, TURN IT OFF!
Tags: cache poisoning, DNS, turn it off
August 27th, 2008 at 8:16 pm
While turning off recursive queries within an organization (really, their name servers) may resolve a piece of the issue – this flaw exists in the foundations of DNS (your query ID for a lookup is effectively your password and it’s a race to respond with the proper query ID… between the proper authoritative name server and the attacker “name” server). Plus, how will you disable recursive queries for ISP name servers (Comcast, Verizon, etc.) – I would suppose this would require the client to perform each lookup (as in, everyones PC) – since the ISP name server wouldn’t be doing the heavy lifting. With home user’s performing all the lookups directly, network utilization would increase by a non-trivial amount due to the additional DNS traffic overhead (at least, I would think so… otherwise, why have recursion and caching in the first place). I think the patches solve this issue in the near term, in the long run DNS probably needs an overhaul (much like IPv4 did), but judging by the adoption rate of IPv6, I wouldn’t hold my breath. Now get ready for this BGP issue to take off like wild fire…
August 28th, 2008 at 12:43 pm
DNS is one of the older protocols around, and it is somewhat fatally flawed (the first response wins is just not a good idea). I agree that it will probably need an overhaul eventually.
As for turning off recursive queries, most DNS requests and responses should generate IP packets that aren’t much more than 100 bytes. Even if you throw on a little more space for the lower level headers (Ethernet, 802.11, or whatever you’re using), and it’s still not very much traffic. Yes there will be a slight delay as the functionality is being moved from the (theoretically faster) DNS server to the end-user, but it will most likely be measured in nanoseconds, if that.