Web Development

Test your DNS name servers for spoofability

In 2008, Dan Kaminsky discovered a way to poison a DNS name server's cache, and then figured out to prevent it. Two years later, some DNS name servers are still not updated. Here's how to check your DNS name servers.

What does DNS cache poisoning mean to us? A lot. Using cache poisoning, bad guys can redirect web browsers to malicious web sites. After that, any number of bad things can happen.

DNS primer

Being human, it's easier to remember names than numbers. But, computers prefer numbers. So we use a process called Domain Name System (DNS) to keep track of both. It translates domain names into numeric addresses.

Let's use web browsers as an example. The user types in the name of a web site and hits enter. The web browser sends a DNS query to the DNS name server being used by the computer. The DNS name server checks its database for the web site's name and responds with the associated IP address. With the IP address, the web browser retrieves the web site.

Too predictable

Two more pieces of the puzzle are needed to understand how Dan Kaminsky can poison DNS server caches. They are:

  • The query transaction ID (allows DNS responses to be matched to DNS queries) is incremented in numeric order and always uses the same port.
  • Applications using DNS explicitly trust the domain name/IP address exchange.

The predictability and blind acceptance allowed him to:

  • Create a rogue DNS response.
  • Send it to the computer or DNS name server asking for the associated IP address.
  • The DNS response is accepted as long as the query transaction ID match and it was received before the authoritative DNS name server's response.

After the dust settled, Mr. Kaminsky realized this technique could be used to redirect web browsers to malicious web sites.

Increase randomness

To prevent redirection, Mr. Kaminsky came up with an elegant solution. There are 2 to the power of 16 possible query transaction IDs and 2 to the power of 16 possible source ports. Why not randomize query transaction IDs. He also suggested using random source ports instead of the same one each time.

If you mix up the selection process for each, the number of potential combinations becomes 2 to the power of 32. That makes it sufficiently difficult to guess.

Okay, we have a solution. But, as I alluded to earlier, not all DNS name servers are using the prescribed fixes. Thankfully, there are ways to tell if the DNS name server is updated.

Testing for spoofability

I was listening to a Security Now podcast with Steve Gibson and Leo Laporte. The topic was "Testing DNS Spoofability". In the broadcast, Mr. Gibson mentioned he developed an online test to see if DNS name servers are susceptible to cache poisoning.

The test is called DNS Nameserver Spoofability Test. The program exchanges a large quantity of DNS queries between the DNS name server being tested and what Mr. Gibson calls a Pseudo DNS Nameserver (courtesy of GRC.com):

The reason so many queries are needed is to accurately test the randomness of the query transaction ID and source port selection.

Router Crash Test

During development of the spoofability test, Mr. Gibson encountered something. The test was crashing certain consumer-grade routers. This link is to the list of routers that do crash. The web page also explains why this is occurring.

Scatter charts

I use OpenDNS for my DNS servers. The following slide shows OpenDNS employs the fixes, creating a random scatter chart:

The next slide (courtesy of GRC.com) represents a DNS server using a selection algorithm that is far less random:

The final example (courtesy of GRC.com) is telling. Both the query transaction ID and the source port are being incremented in a linear fashion. Although the values are changing, it is in a predictable fashion. Not good.

Find a public DNS provider

There are alternatives if you find the assigned DNS name servers are not randomizing the entries sufficiently. I mentioned earlier, that I use OpenDNS. It is free, and it is the only public DNS service that offers protection from DNS rebinding attacks. This GRC.com web page has a list of other public DNS providers.

Final thoughts

To avoid problems resulting from being redirected to a malicious web site, please test the DNS name servers used by your computer.

About

Information is my field...Writing is my passion...Coupling the two is my mission.

22 comments
PhilippeV
PhilippeV

Is that because of this article ? But the "DNS Nameserver Spoofability Test" is completely unreachable for me (OpenDNS does not resolve "grc.com")

PhilippeV
PhilippeV

DNS poisoning will be used by spammers that have considerable ressources. The soltuion is clearly not sufficient because they have huge armies of zomby hosts to experiment it. First: it's impossible to use the full 16-bit range of source ports. Because some subranges are needed for interoperability with other services in the source host, or reserved for some other protocols needed for correct management of routings (so they will be restricted by a front-side firewall. OK, let's admit that we can safely configure any DNS server to use between 32K and 48K sources ports, this gives at least 15 bits of randomness there. Second: the querry number can effectively be randomized, but this is not the job of the DNS server, but of the DNS client (of of the proxying DNS cache that will be quertying the upstream DNS server). But anyway this just give 31 bits of randomness, and this is clearly insufficient against attacks performed by armies of zombies controled by spammers. Yes they can perform such attacks massively, without being identifiable from a single source (they have the time to do that aver several days, until the poisoning finally works and their spews get delivered to the targetted ISP's clients to redirect them to the unintended sites. The only thing that should be performed is, for any large enough ISP (with enough target clients for spammers to justify such poisoning attacks against the DNS cache of an ISP) is to have these caches performing qeries to upstream DNS's using secure connections (so that source spoofind will not be possible), i.e. using IPSEC as muc has possible, and maintaining a large enough base in their cache, for all major registries, using verifications by querying domains from the root, instead of directly the intended domain, to make sure that the DNS servers are effectively authoritative. Here is DNS poisoning occuring ? In most cases it is within the DNS caches provided by your ISP. Large ISPs (with about 100,000 clients or more) will be the most profitable targets of these attacks (to avoif this, large ISPs tend to split their customers by assigning them to distinct DNS caches, so that any poisoning from one will not propagate to the other one). Another solution is for ISPs to have all DNS cache instances to run under the control of another master DNS server that will be in charge of performing cleanup after verifying in priority the most queried domains: they will reverify (in an asynchronous way) the informations, and will make sure that the infos provided from some other upstream DNS or unknow remote DNS server is effectively authoritative. Then this master DNS server will inform the various DNS cache instances by requerying them for these domains: as the DNS caches will be configured to first request the master DNS server, they will be flushed immediately from the false info (poison) that they have received from malicious fake DNS servers. But really, what is the world waiting for ? All registries (and their registrars) should upgrade to support DNSSEC where spoofing is not possible. Large ISPs will be able to use almost permanent secured TCP sessions to these registries from their master DNS server, and all their DNS caches will just have to query the master DNS server (locally, without even using the Internet, by working in a DMZ) to get infos that they must cache and reply to the ISP's clients (these caches can even reduce the lifetime in their cached data, even if the authorititative info seems longer as reported to the local master DNS server). Now let's focus on the major problem: it is not within domains registered in the public orldwide registries. But for the subdomains: most domains should really ask themselves before they decide to implement their own DNS server for the subdomains. In my opinion it will be best to have the domain and all its subdomains hosted on the same DNS server, preferably hosted directly at the registrar, only because the registrars are better equipped (with also a permanent supervision with specialized teams wroking 24/27, 7/7) to get autoritative answers (and private communications to be informed very fast and secrurely from ongoing attacks) occuring from any place in the world. Registrars have also direct and secure links to the resgitries with which they are working; and all registrars can deply DNSSEC. I just wonder why DNSSEC is still not deployed worldwide against such spoofing, in all registrars on the side of domain registrants, or by major ISPs on the other side of clients for the links connecting their master DNS server to the registrars. And why are people deploying their own DNS cache ? Given the speed it takes to resolve domains from the upstream ISP, it is no lonver justified: just use a vvery small cache locally and configure it so that all data in it will be flushed rapidley adter a few minutes: don't configure any DNS cache (including in your PC for your single Internet conenction used by your browser) to maintain data for more than several minutes. And let's militate so that our ISPs will provide us with Internet connections configured with a good DNS server for our connection. If not, convert to OpenDNS or to GoogleDNS. But still, OpenDNS does not support DNSSEC for everyone (it would be very constly to support on their limited architecture): if DNSSEC was really deployed everywhere, the performace issue would no longer exist : we could increase a lot the lifetime of DNS data, and the volume of queries would shrink as well, except for the spike of DNS traffic of newly registered domains, or domains that suddenly get some high exposure after some news event... Let's not forget that the DNS worldide is highly redundant and was built to support such spikes of traffic very well (it is very scalable due to the massic adoption of multilevel DNS caches). Let's secure all the upstream levels that support the largest traffic. The historic basic DNS protocol should be deprecated and shutdown worldwide.

JCitizen
JCitizen

It is good to revisit this subject; I learned a few new things and it seemed like we left the subject hanging a while ago. The graphs really woke me up on how to perceive the randomness factor! Thanks for that Michael! I don't know if my service is spoofable or not. I'm using Comodo for now. Hopefully I'll have time to read and study the GRC site to find out more on how to test it.

dayen
dayen

I am having them tested called in the Consultants now I will get the routers check too !!

Michael Kassner
Michael Kassner

It is possible to poison a DNS servers cache. That's means your computer could be redirected to a malicious web site without you knowing it. There are fixes for the problem, but not all DNS name servers are updated. Find out if your are. Edit: Spelling

Michael Kassner
Michael Kassner

It is 1330 CDT and I can run the test. Sorry for the inconvenience.

Michael Kassner
Michael Kassner

Some questions: Why would spammers be using it? To send people to their web sites? Great point of the DNS client randomizing the queryID. I have asked the same question about DNSSEC and do not get any real answer. As for local DNS cache, I agree. There is another reason as well. Local caches usually do not have the right information anyway. I determined that when I was researching this article about DNS benchmarking: http://blogs.techrepublic.com.com/networking/?p=3580&tag=results;CR1

JCitizen
JCitizen

you automatically go through their DNS servers. It has saved my bacon a few times!

Neon Samurai
Neon Samurai

Nice and fast, faster than my ISPs lookups anyhow.

JCitizen
JCitizen

I remember reading that in Cisco school! I've been away from college too many years! :(

Michael Kassner
Michael Kassner

Did you read my article about benchmarking? DNS servers covering a small number of users will have a small cache. so they have to go out to the authoritative DNS name server. The benchmarking tool will clearly show that. It was the surprise that caught me.

JCitizen
JCitizen

of using your own servers. My requirements are too small for such. I really should buy one and set it out on the DMZ just to keep up though. But then I wouldn't have time for anything else for a while. :)

Michael Kassner
Michael Kassner

At least for me it is. My network adapter DNS name server setting override everything else.

JCitizen
JCitizen

that if I set them in my gateway, that would preempt any software settings in my PC. So far I like the way it is. You can always simply not check the [b]"Use Comodo DNS servers"[/b] selection upon installation of the firewall if you don't like the service. Also - I assume you can always issue the "flush DNS" command line, if you have already uninstalled a previous instance of Comodo Firewall.

JCitizen
JCitizen

and it seems to override my gateway DNS. Checkpoint also offers DNS services, but I haven't checked my settings there for a few years. I suppose now I should pay more attention to the matter. I assume if I issued the flush DNS command line, it would reset to default? (edited) I checked my settings in the PC and they are on automatic, just as normal inside a LAN with no server.

Michael Kassner
Michael Kassner

Interesting. Do you leave the network adapter setting to automatic?