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:
- Attacker persuades victim to ask for 1.example.com
- Victim’s DNS server queries for an A record for 1.example.com
- 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 188.8.131.52”
- Victim’s DNS server accepts this response, queries 184.108.40.206 for 1.example.com, and now the attacker knows that the victim can be directed to www.example.com at 220.127.116.11, 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 18.104.22.168, 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:
- Because the attacker tells the victim to search for a site, the attacker controls when the race with the authoritative DNS server starts.
- 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.
- 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.
- 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:
- 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.
- 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.
- 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.
- Users are being advised to point their DNS server entries to OpenDNS. Single point of failure, anyone?
Metrics and statistics:
- 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.
- 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.
- 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.