For those of you that aren't aware, Dan Kaminsky with IOActive recently coordinated a massive multi-vendor update to several DNS server applications, including ISCs BIND which powers the vast majority of DNS servers in the world.  Details are not available on the vulnerability yet, but it is being described as a fundamental flaw in the DNS architecture itself (a design flaw, he has said).

The patches released by multiple vendors last week is an attempt to mitigate the vulnerability and make it harder to exploit, it does not fix the underlying flaw which has not yet been published.  These patches are almost exclusively aimed at ensuring DNS servers use a random source port for every query they send out; most, including BIND, simply picked a random port on startup and use that as the source port for all of their queries.

This makes a DNS server much more more susceptible to DNS hijacking and thus cache poisoning.

Hijacking is the act of sending a forged response to a query that reaches the server before the legitimate answer gets there.  If the source IP and query ID match, and the spoofed answer is sent to the right port, there is no mechanism (outside of DNSSEC which is not widely deployed) to determine if the answer is authentic or not.

Cache poisoning uses hijacking to inject additional records into the victim's DNS server; rather than attempt to explain the differences, I will illustrate them at the end of this post.

It appears then that DNS hijacking, while not the vulnerability that Kaminsky has discovered (hijacking and cache poisoning are old news), is a required step in exploiting the vulnerability.  If you are resistant to hijacking, you are by definition resistant to cache poisoning and the new as-yet-undisclosed design flaw.

I want to stress that this is an entirely new flaw.  Pretty much everyone was skeptical about it at first, and many people grew (and are growing) more irritated by the second that the vulnerability has not yet been disclosed.  Some people have even suggested that Kaminsky simply "discovered" cache poisoning all over again in an attempt to get his name up in lights.

This is not the case.  Paul Vixie (Author of the BIND nameserver), Cricket Liu (Author of DNS & BIND), Paul Mockapetris (Inventor of DNS), and others have been clued in to the vulnerability in detail by Kaminsky.  They are all well respected authorities on DNS and in the security field, and would not simply throw away their reputations crying wolf over nothing.  It also takes more than a single lunatic screaming about TEOTWAWKI to get Microsoft, ISC, Cisco, and other big name vendors to sit down in a room skeptics and walk out committed to releasing the same patch, for the same issue, on the same day.

Details are to be released in a few weeks at the Blackhat conference in Las Vegas, so if you haven't patched already, make sure you do before then.  Once the vulnerability is disclosed, expect an escalation in attacks from script kiddies shortly thereafter.

You can use free tools provided by DNSstuff, Doxpara (Dan Kaminsky), or DNS OARC to check if the DNS server your system is currently configured to use has been patched or not.

If anyone has any questions about the vulnerability or how the tests work, how to use them, or the vulnerability, go ahead and ask away.  I'll answer as much as I can.

Vulnerability notice from US-CERT: www.kb.cert.org/vuls/id/800113

I promised to provide an example of hijacking and cache poisoning and forgot to do so, so here it is.

First, a note on how DNS works for you (read: normal peoples).  When you go to www.ar15.com, your browser asks the local resolver (called a stub resolver) for the IP address, via a function called "gethostbyname()."  If the stub resolver has already performed this lookup and has the address cached, and the cached information is still valid, it returns the address and life goes on.

If the stub resolver does not have the address in its cache, or the cache has expired, then it attempts to look up the name via your configured DNS server.  For most people, this is the IP address of a DNS server your ISP provides, which is setup to allow recursive queries from its customers.  It is important to note that the DNS server a workstation is configured to use must be setup to either do recursive lookups itself, or forward queries to a server that does recursive lookups.  The stub resolver cannot do iterative lookups on its own.

The recursive nameserver then follows generally the same rules as the stub resolver, but will perform additional lookups as needed.  If www.ar15.com is not in its cache or the cache is expired, it will check to see if it has the data needed to look up the query directly; this means it needs the SOA and NS records for ar15.com, and the A records for the nameservers, so it can ask the ar15.com DNS servers for the address.  If this information is also expired or not cached, will do the same thing for the .com TLD, and if that in turn is expired or not available, it will start the entire query chain from the root servers, which all servers have available via a list that is distributed with them.

A hijacking attack is used against the recursive nameserver, yours if you run one of your own (as I do), or your ISPs if you use theirs (as most everyone does).  When your ISP goes out to look up the address of www.ar15.com, if the attacker sees this query or knows they just made it through other means, they can respond to it with a forged answer sending you to the wrong address.  All they need to know are the connection details (source and destination IP addresses and ports) and the query ID.  If they are sniffing your ISPs DNS traffic, all of this information is available to them.  In most cases, they don't have this information, so they have to guess, and send out a ton of bogus responses, most of which will be silently rejected.

If they guess right, and their forged replies reach your ISPs nameserver before the legitimate reply, then they've won.

This is informally known as DNS cache poisoning, though I look at cache poisoning as this plus one more bit.

In a normal DNS query for a domain name, a legitimate DNS server will not only send you the answer (A record) you are looking for.  The server will also attempt to help you with future queries by sending you a list of authoritative nameservers (NS records) and their addresses (A records) along with the answer you asked for.

This only happens in a few select cases; usually when the query is looking for an SOA or NS record.

However, a malcious attacker can populate their response with data like this in order to preemptively attack you.  Your cache can thus be "poisoned" with records you have not yet asked for, but might ask for in the future.

In a worst case scenario, the query from the recursive nameserver for the .com NS records could be spoofed, and send along records for .net, .org, and other TLDs along with the answer, effectively poisoning the server against the entire internet.  In a successful attack of this nature, you (and all your ISPs other customers) will have all their internet traffic that relies on DNS for name resolution redirected elsewhere.

This type of attack only has to work once.  If the malicious network is stable, the packets can have TTLs of weeks or months, meaning the bogus records can be cached by the ISP for that long before the DNS server again attempts to look up the authoritative nameservers for a hijacked TLD.

Protecting yourself.

Thankfully, there are some things you can do to protect yourself; you can't really prevent these types of attacks, but you can usually detect them if you are vigilant.

First, keep a list of reliable nameservers that are open to the public and provide recursion.  OpenDNS provides such a service, and it's likely that your ISPs upstream bandwidth providers will allow recursion from you, as you are inside their network.  You will need these addresses if your ISPs nameserver ever does become compromised.

Second, never ever ever enter sensitive data into a site that isn't encrypted with 128bit SSL (or stronger, once it is available).  If you see a warning that an SSL cert has expired or anything of that nature, eject!  Even if your DNS is hijacked and you are sent to a malicious website, that website still cannot (practically.  I'm sure the CIA and the Chinese can...) forge the SSL chain of trust, unless verisign and the other root CAs have their signing keys stolen.

Third, install the 'dig' utility (it comes with BIND from ISC).  Chances are you personally are not going to be attacked with DNS cache poisoning, it will be your ISP that is attacked.  Dig has a trace option that forces it to ignore all your DNS settings and the local stub resolver cache, and query the entire DNS chain to find the answer.  It starts at the root servers which it has a list for internally, and works it's way down from there.  You can use this to compare the address it returns for a server to the address returned for something like ping.  This is not foolproof, as sites using DNS based load balancing may return different results each time you run the tool, but it's a start.

Fourth, if you can spare a machine to act as a DNS server on your local network, do it, and use it instead of your ISPs nameserver.  If its cache does get poisoned, which is highly unlikely, you can simply restart it to clear the cache.  Do not configure it as a forwarder.  Simply enable recursion and use it as your DNS server instead of whatever your ISP says.  If you can't spare a computer to act as a server, you can still run one on your computer itself and use that.  The resources required are minimal.

named restart