After patching my DNS servers, I went about testing that the patch was working. I confirmed this with a tcpdump of DNS traffic. The source ports of outgoing queries leaving the DNS servers were indeed being set to a randomized UDP port.
However, I then tested my DNS server using the Check My DNS tool on Kaminsky’s blog site. I was surprised to see that the source port was no longer randomized. As the DNS queries leave our private corporate network for the public Internet, our NAT gateway is rewriting the random UDP source ports to a predictable sequential series of source port numbers: 14756, 14757, 14758, etc. Apparently, the NAT gateway is reducing the effectiveness of the additional entropy introduced by the random source ports.
More detail about how I performed the tests can be found in this blog posting.
So, are we at risk? Yes, and no.
We’re definitely better off than we were before the patch. As pointed out in a previous post, anyone who can make a recursive query can poison an unpatched DNS server. In our case, the DNS server is patched. That’s good. If an attack is operating entirely within our private network against our private DNS server, then we’re safe. It will be very difficult for an attacker to properly guess which random port the DNS server is using for a given query.
However, if the attack is being coordinated from both within the private network and from the public Internet, then we are still at a somewhat high risk of poisoning. The attacker can take advantage of the reduced source port entropy of DNS queries passing through NAT. The attacker need only initiate a recursive query from within the private network, while simultaneously attempting to poison the response from the public Internet. Because the query’s source port is no longer randomized following NAT translation, the attacker would need to send bogus replies to a small series of sequentially numbered ports on the NAT’s external IP address.
Unfortunately, our NAT gateway vendor does not yet have a patch available.
In the meantime, I will install a new DNS server in our corporate DMZ network to which all internal DNS servers will forward recursive queries to.
I’ve been spending a lot of time thinking about this lately as well.
Unfortunately, I think the “co-ordinated internal/external” attack is precisely what we are likely to see. Imagine that the attacker puts up a webserver to lure in users and then poison their DNS. He is then in a position to cause visitors to initiate queries, and he also knows what ip address those queries will come from. He is essentially co-opting the local user’s browser as the inside component of the attack vector. Moreover, he can start sending responses simultaneous to their query, giving him an advantage in the race to reply.
It’s a little bit more complicated than the current metasploit exploit, but I’d imagine it has already been done somewhere.
Let’s all hope the major firewall vendors patch and patch soon.
-Ryan
@Ryan
Thank you for that additional insight about a user’s browser being co-opted as the internal component to the coordinated attack. It’s definitely plausible, especially given recent escalations in the sophistication of malware used to infect desktop computers. The browser would simply need to make a query every 1 second to initiate each subsequent attempt.
And of course, it goes without saying. Given the amount of money transacted on the Internet today, the number of possible web sites to target, and the relative ease involved with infecting an unpatched DNS server, it is probably just a matter of time before the cyber-criminals develop an effective means of exploiting that scenario.