The SANS Institute installed and tested out Apple’s fix for the underlying flaw in the domain name system (DNS) protocol, and found that a patched copy of Mac OS X 10.5 Leopard (the desktop version, not Leopard Server) still suffers from the risky technique that makes DNS vulnerable to exploitation.
This exploitation, so far, seems extremely unlikely, but we won’t know how unlikely until security researcher Dan Kaminsky, the discoverer of this flaw, provides full disclosure on 06-Aug-08 in his Black Hat conference talk, “Black Ops 2008: Its (sic) the End of the Cache as We Know It.”
As Rich Mogull and I noted in “Apple Fails to Patch Critical Exploited DNS Flaw” (2008-07-24), servers are at a high risk from this DNS vulnerability. The flaw allows an attacker to send tens of thousands of fake responses for a DNS query to a server, which then poisons the server’s DNS entries if the attacker matches the right pattern with their forged information before the legitimate response arrives from the DNS server for the domain that’s being queried.
However, computers used by individuals without DNS server software in operation are also vulnerable to this flaw in DNS; we just don’t know yet quite how vulnerable. With servers rapidly being patched worldwide, it’s likely that the low-hanging fruit has largely disappeared, and attacks would then turn to clients – if clients are readily exploitable, too. Clients use stub resolvers, which forward requests for DNS answers to a full-blown, or recursive, DNS server run by their company, ISP, network provider, or co-location facility.
These clients pass their requests along, and it seems unlikely that they could be attacked directly unless an attacker had a computer on the same local network segment as the exposed system. In that case, the attacker would have a panoply of other network information poison available, and could disrupt DNS in a more efficient manner.
The DNS flaw relies on predictability in how ports are assigned to outbound requests for domain name lookups in a DNS query. An attacker forces a DNS server to look up a domain using a DNS server the attacker controls, and from that obtains the current port number being used for requests. If the ports are sequential – each query increments by one the port number used for each subsequent request – then the attacker starts sending forged requests using ports numbered just above the one it sniffed.
This is part of the question about client vulnerability: it’s very hard to force a client to look up an evil domain to prime the pump because clients don’t answer DNS queries to begin with, and typically aren’t running mail servers which can be gamed when an attacker sends incoming email with an evil domain in the return address.
By increasing entropy – choosing a random port for each request – a patched DNS server prevents attackers from producing enough packets quickly enough to win the race with the legitimate DNS server, such that they cannot – statistically speaking – poison the DNS cache. (This is a patch, not a fix, actually; DNS itself must be overhauled to remove the fundamental weakness.)
I checked out my updated Leopard desktop system, and, sure enough, I saw precisely what SANS reported: sequential UDP ports returned in response to outbound requests, regardless of what this entails.
If you’d like to duplicate the SANS experiment, follow these steps:
- Launch Applications > Utilities > Terminal.
- Type the following, entering your administrative password when prompted.
- Open another Terminal window, and in it, type the following, press Return, and then press up arrow and Return a few more times to enter the command repeatedly:
- In the window with tcpdump running, you should see a series of lines that look like the following.
- Press Control-C (not Command-C) to stop tcpdump from running.
sudo tcpdump | grep domain
15:06:53.900835 IP 192.168.1.16.49229 > yourDNSserver.com.domain: 5228+ PTR? 184.108.40.206.in-addr.arpa. (43)
15:06:53.947838 IP 192.168.1.16.49230 > yourDNSserver.com.domain: 48400+ PTR? 220.127.116.11.in-addr.arpa. (43)
15:06:55.003628 IP 192.168.1.16.49231 > yourDNSserver.com.domain: 15730+ PTR? 18.104.22.168.in-addr.arpa. (43)
(If you don’t see any results in step 4, you need to specify the network adapter with the tcpdump command. You can try en1, en2, en3, and so forth as in the following command.)
sudo tcpdump -i en1 | grep domain
We’re not back where we started, because clients are enormously harder to attack. But it’s still a hole that needs to be filled. We just won’t know how deep a hole until next week.