This site is now 100% read-only, and retired.

DNS Survivial Guide

Posted by simonw on Mon 14 Jul 2008 at 10:38

Hopefully you've all heard of CERT VU#800113, this is for people who didn't understand it.

What is wrong?

We don't know as the issue hasn't been fully disclosed.

But we know that the DNS protocol is vulnerable to attack because the way a DNS response is validated is to check the transaction ID ( hence forth called "TXID") a 16 bit number sent with a request, matches the TXID in the answer.

  • The response needs to come from the IP address the request was sent to.
  • It needs to come back from port 53 on the remote server, to the port that sent the request.
  • It needs to have the same TXID.
  • It needs to answer the question asked (in some way?! It can contain additional information!).
  • It needs to arrive first, since the first answer that matches will be accepted and close down the outstanding query.

For many recursive DNS servers it is not hard to force them into sending known DNS queries (Emails, JavaScript, trojans, or just signing up with the target ISP as a customer) at a specific time, hence it is possible to spoof timely answers to those queries and put corrupt data into the recursive resolver.

If you can observe the DNS queries on the wire, you can just read the TXID and send back the packet expected.

If you can't observe the DNS queries, but you can force the resolver to query one of your DNS servers, you know IP address, and source port. Thus all you need to spoof the query is to guess a TXID, and some luck in getting your spoofed answer back before the genuine one (a quick DDoS attack on the real authoritative servers might help here!). Given there are only 65536 TXIDs you'll hit lucky one times in 65536, which means it isn't that hard to do even without whatever Dan's great announcement is.

The recommended "hack" (it is not a proper fix) is to enable source port randomisation. So that the query may come from any port in the ephemeral port range, so that we now have 65536 x [size of emphemeral port range]. My estimate is this takes a naive spoofing attempt with a million spoofed packets arriving in timely fashion a day to a recursive resolver from a few hours to succeed in a spoof, to a few years, on a typical Debian DNS server running BIND9.

This fix does nothing to protect you against the attack where the DNS query can be inspected by the bad guys, you'll have to live with that one for the moment (you have done till now!).

What is the ephemeral port range for IPv4 on recent Linux kernels?

$  cat /proc/sys/net/ipv4/ip_local_port_range

# My system has:
$  cat /proc/sys/net/ipv4/ip_local_port_range
32768   61000

What to do?


Dan Bernstein's dnscache has always used source port randomisation.

With BIND you want to be running 9.5.0-p1

This is already released for Debian see: Thus all Debian servers running Etch, Lenny or Sid, which are fully patched should be fine.

I don't run a recursive DNS server - could this affect me?

Well someone runs a recursive DNS server for you!

For example my broadband router at home will forward DNS queries to a couple of DNS servers run by Entanet. When I tested I found that people connecting to my router (and relying in its DNS settings) were having their DNS queries forwarded to DNS servers that aren't yet patched.

How can I check if my recursive resolvers are fixed?

Duane Wessels put together a nice little checker here....

$ dig +short TXT

Dan Kaminsky has a Javascript checker here

Duane's checker is handy, as you can use the "dig @IP.AD.DR.ES" syntax to check all the name servers in your /etc/resolv.conf file without having to comment the others name servers out.

A Good result for

$ dig +short @ txt
" is GOOD: 26 queries in 4.3 seconds from 26 ports with std dev 16739.26"

$ dig +short  @ version.bind chaos txt

A not so good result for my ISPs name servers (I'm sure they'll upgrade them soon)

$ dig +short @ TXT 60 IN TXT " is POOR: 26 queries in 45.9 seconds from 1 ports with std dev 0.00"

$ dig +short @  version.bind chaos txt

What else could/should be done?

Ultimately DNS needs proper security - one proposal is DNSSEC. DNSSEC uses cryptographic signatures to validate the answers. This would stop both types of attack discussed above, but at the cost of increased complexity in the management of domain names.

ISPs also need to prevent spoofing of IP addresses. The attack outlined only works if you can spoof the source address on the response packets. In well run ISP networks this behaviour is prevented by appropriate routing configuration.

Best Current Practice: Network Ingress Filtering - May 2000

Other - until the details are released we can't know for sure the scope of the problem. All we know is people entrusted with the DNS are taking it seriously. Although given how bad current exploitation of DNS spoofing could be it is hard to imagine how it could get much worse than the obvious. On the upside it is still considered too much like hard work by the many spammers and other bad guys, but that is probably a reflection on how easy it is to own half a millions websites by SQL injection.



Re: DNS Survivial Guide
Posted by kevmitch (154.20.xx.xx) on Mon 14 Jul 2008 at 22:03
Thanks, this article was exactly what I was looking for!

[ Parent ]

Re: DNS Survivial Guide
Posted by Anonymous (89.16.xx.xx) on Tue 15 Jul 2008 at 14:46
Are dns clients affected? From what I read if the attacker is between me and my DNS server I`d still be vulnerable.

[ Parent ]

Re: DNS Survivial Guide
Posted by simonw (89.16.xx.xx) on Tue 15 Jul 2008 at 18:46
[ View Weblogs ]
Good question.

As regards the specific CERT advisory I don't know. I believe Microsoft's recommended patches include changes to client resolver logic but that may be to deal with different problems in Microsoft name resolution (it is a worse mess in the Microsoft world).

If the attacker is between you and your recursive DNS server, it is game over, because he can read the queries (and the TXID) and send any answer he likes.

An external attacker could spoof responses to individual machines (stub resolvers). It is generally slightly harder to persuade end user machines to make the DNS lookups you want, when you want. Also stub resolvers are generally closer to the recursive resolver, so the network is (hopefully) more tightly controlled, and thus more resilient against spoofing. Also the local recursive resolver may well provide an answer before the spoofed answer arrives.

So whilst I think it is possible against badly run networks, I think stub resolver are a much less attractive target than recursive resolvers.

[ Parent ]

Re: DNS Survivial Guide
Posted by Anonymous (124.171.xx.xx) on Mon 28 Jul 2008 at 11:39
It looks like there isn't a patch for Sarge and VU#800113 - is that correct?
My source ports are still super non random (in fact they are the same port) and I'm using latest bind9


[ Parent ]

Re: DNS Survivial Guide
Posted by simonw (212.24.xx.xx) on Mon 28 Jul 2008 at 12:23
[ View Weblogs ]
Sarge is no longer receiving security support, so no patch for Sarge.

I upgraded recursive DNS servers here to Etch.

Since they had practically no other software on them it was relatively trivial.

One could presumably compile BIND9 from the ISC tar ball easily (or another recursive DNS server application).

Note that DNS clients are at risk (in theory) so any server not covered by security support will lack DNS source port randomisation.

One of those issues that shows why keeping within security support is important. Although I have servers running Sarge, and appreciate management don't always give it the priority it deserves.

[ Parent ]