Kaminsky Black-Hat Webcast: "By Any Other Name: DNS has doomed us all."

By any other name... Okay, so the talk’s official title was “Dan Kaminsky’s DNS Discovery: The Massive, Multi-Vendor Issue and the Massive, Multi-Vendor Fix”.


Arcane details of TCP are something of a hobby of mine, so I attended the webcast to see what Dan had to say.


The Past is Prologue


A little history first – six months ago, Dan Kaminsky found something so horrifying in the bowels of DNS that he actually kept quiet about it. He contacted DNS vendors – OS manufacturers, router developers, BIND authors, and the like – and brought them all together in a soundproofed room on the Microsoft campus to tell them all about what he’d discovered.


Everyone was sworn to secrecy, and consensus was reached that the best way to fix the problem would be to give vendors six months to release a coordinated set of patches, and then Dan Kaminsky would tell us all at BlackHat what he’d found.


Until then, he asked the security community, don’t guess in public, and don’t release the information if you know it.


Now is the winter of our DNS content (A records and the like)


Fast forward a few months, and we have a patch. I don’t think the patch was reverse-engineered, but there was enough public guessing going on that someone accidentally slipped and leaked the information – now the whole world knows.


Kaminsky confirmed this in today’s webcast, detailing how the attack works, to forge the address of www.example.com:


  1. Attacker persuades victim to ask for 1.example.com
  2. Victim’s DNS server queries for an A record for 1.example.com
  3. Attacker forges a response that says “I don’t know 1.example.com, but the DNS server at www.example.com knows, and it’s at 1.2.3.4”
  4. Victim’s DNS server accepts this response, queries 1.2.3.4 for 1.example.com, and now the attacker knows that the victim can be directed to www.example.com at 1.2.3.4, allowing the attacker to steal cookies, represent as a trusted web site, etc, etc.

Note that this is a simple description of the new behavior that Kaminsky found – step 3 allows the DNS server’s cache to be poisoned with a mapping for www.example.com to 1.2.3.4, even if it was already cached from a previously successful search.


If that was all that Kaminsky could do, even on an unpatched server, he’d have a 1 in 65535 chance of guessing the transaction ID to make his forgery succeed. However, old known behaviours simply make it easier for the attacker to make the forgery work:


  1. Because the attacker tells the victim to search for a site, the attacker controls when the race with the authoritative DNS server starts.
  2. The attacker can tell the victim to search several times, and can forge several possible responses, using the birthday paradox to be more likely to guess the transaction ID (and source port), so that his forged response is accepted.
  3. Because this attack overwrites cached entries, the attacker can try again and again (picture a site with a million 1-pixel images each causing a different DNS query) until he is successful. Stuffing the cache won’t protect you.
  4. The attacker can insert an obscenely huge TTL (time-to-live) on the faked entry, so that it remains in cache until the DNS service is flushed or restarted.

Kaminsky’s tests indicate that a DNS server’s cache can be poisoned in this way in under ten seconds. There are metasploit plugins that ‘demonstrate’ this  (or, as with all things metasploit, can be used to exploit systems).


The patch, by randomizing the source port of the DNS resolver, raises the difficulty of this attack by a few orders of magnitude.


The long-term fix, Kaminsky said, is to push for the implementation of DNSSEC, a cryptographically-signed DNS system, wherein you refuse to pass on or accept information that isn’t signed by the authoritative host.


A port, a port, my domain for a port


One novel wrinkle that Kaminsky hadn’t anticipated is that even after application of the patch to DNS servers, some NATs apparently remove the randomness in the source port that was added to make the attack harder. To quote Kaminsky “whoops, sorry Linksys” (although Cisco was one of the companies he notified of the DNS flaw, and they now own Linksys). Such de-randomising NATs essentially remove the usefulness of the patch.


Patching is not completely without its flaws, however – Kaminsky didn’t mention some of the issues that have been occurring because of these patches:


  1. ZoneAlarm decided that DNS queries from random source ports must be a sign of attack, and denied all such queries, essentially disconnecting the Internet from users of ZoneAlarm. I guess I can learn to live with that.
  2. BIND doesn’t check when binding to a random port to see if that port is already in use – as a result, when the named server sends out a DNS query, there’s a chance the response packet will come back to a service that isn’t expecting it. Because the outgoing query punches a return hole in most firewalls, this could mean that a service blocked by the firewall from receiving Internet traffic is now opened up to the Internet. The workaround is to set the avoid-udp-v4-ports configuration setting, listing any ports that named shouldn’t use.
  3. Windows’ DNS service takes a different tack, binding to 2500 (the number is configurable) random ports on startup. As with BIND, these ports might conflict with other services; different from BIND, however, is the behavior – since the ports are already bound by the DNS server, those other services (starting later than DNS, because most IP components require it) are now unable to bind to that port. As with BIND, the workaround is to tell the DNS server which ports not to use. The registry entry ReservedPorts will do this.
  4. Users are being advised to point their DNS server entries to OpenDNS. Single point of failure, anyone?

Metrics and statistics:


  1. When Kaminsky’s vulnerability detection tool was first made available at doxpara.com, 80+% of all checks indicated that the DNS server was vulnerable. This last week, 52% of all checks showed vulnerable servers. Patches are getting installed.
  2. The attack is noisy – output from the metasploit framework showed “poisoning successful after 13250 attempts” – that’s thirteen thousand DNS queries and 260,000 forged DNS responses. IDS and IPS tools should have signatures for this attack, and may be able to repel boarders.
  3. Metasploit exploits for this are at http://www.caughq.org/exploits/CAU-EX-2008-0003.txt if you want to research it further.

Tomorrow, and tomorrow, and tomorrow…


The overall message of the webcast is this:


This attack is real, and traditional defences of using a high TTL will not protect you. Patching is the way to go. If you can’t patch, configure those unpatched DNS servers to forward to a local new (patched) DNS server, or an external patched server like OpenDNS. Scan your site for unexpected DNS servers.

2 Responses to Kaminsky Black-Hat Webcast: "By Any Other Name: DNS has doomed us all."

  • Joe Krahn says:

    I think that faked DNS data should not be such a security problem. Any data that is worth protecting should be encrypted with authenticated certificates. With the popularity of roaming wireless internet, there are too many opportunities for modifying DNS information, mis-routing and packet sniffing.

    Maybe it is too much to ask for regular users to be aware that unencrypted communications should never be trusted. One possibility might be to implement an SSL host-verification before any other connection to a remote host.

    I’m not a network programmer, so there may be other issues, but a simple host verification seems like a good way to avoid more than just DNS hacks (and without the complexity of SecureDNS).

  • alunj says:

    Ah, but there are other games you can play with DNS that cause users to work against that education.
    What if you visited your favourite bank and their home page advised you “please download and install a new root certificate from Verisign”, and pointed you there to fetch the new cert?
    Maybe you or I wouldn’t get caught out, but a lot of users – even those who have been told to always use certificates to prove server identity – will simply install the new certificate (after all, it appears to come from Verisign), and carry on back to the fake banking site, which now identifies with a real padlock.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>