Responding to the DNS vulnerability and attacks
Posted by Tom Cross on July 25, 2008 at 7:21 PM EDT.
We've been hearing four primary questions from customers about the recently disclosed DNS cache poisoning vulnerability; How do I tell if I'm vulnerable, what do I do to mitigate it, how do I tell if I've been attacked, and what do I do if I've been attacked. We put this blog post together in an attempt to address those questions directly.
How do I tell if I'm vulnerable?
A tool on the right hand side of Dan Kaminsky's blog does a decent job of testing your DNS resolver to see if it is vulnerable. There are also very informative tools hosted by DNS-OARC including a browser based tool and a tool that can be used through dig on the command line. The perspective that these tools have is not absolutely definitive. Attackers on the local network may have vectors available to them that these tools cannot test. However, it is our opinion that these tools faithfully simulate the approach that most remote attacks are likely to take, and so they provide a very valuable reference.
What do I do to mitigate the vulnerability?
The US-Cert bulletin offers very good advice for mitigation. In general, you need to make sure that your DNS clients and servers are patched. There is an update available for Internet Scanner that will check Microsoft Windows clients and servers for the necessary patches, but you need to check Unix servers as well.
Furthermore, if you have a server behind a NAT device, some NAT devices will undo the UDP port randomness introduced by the patch. Fortunately, Linux iptables and OpenBSD's pf are not vulnerable, but many popular NAT devices are. If you have such a device you can either move your DNS server to a DMZ segment where it need not be NATed, or you can forward requests from that DNS server to a patched server that is not behind the NAT. If you forward make sure that you disable recursion.
If you are unable to patch a server, you can mitigate some attack vectors by forwarding requests from that server to a patched server. OpenDNS is one example of a patched DNS service that will accept forwards. Again, if you forward make sure that you disable recursion.
If you are relying on your ISP's DNS infrastructure, either directly, or through a forward, and the testing tools above are indicating that you are vulnerable, you may need to escalate the issue with your ISP.
How can you tell if you’ve been attacked?
It is possible to detect DNS cache poisoning attacks with Proventia IDS/IPS. You will see a large number of DNS_Cache_Poison events firing on your console, and the event information will reference different query host names for hosts within the same domain that appear to be randomly or automatically generated, such as lgUuW5jf79GR.domain.com, P86DmEfpci3v.domain.com, etc... These hosts will not usually resolve.
However, if you don't detect the attack with an IPS your first observation might be that there is something suspicious about an Internet resource, such as a website, that you use. Eventually in investigating the matter you might determine that the IP address that your name server is resolving for that resource is not the right IP, or not the same IP that is reported by web based nslookup services. However, note that large web sites that employ different kinds of load balancing solutions might return different IP addresses for the same name lookup made from different networks or locations or at different times, so the fact that two locations are reporting different results is not, by itself, evidence of cache poisoning.
What to do if you’ve been attacked?
Remember to apply Occam's Razor. In practice the vast majority of incidents of unexpected or suspicious computer behavior that are initially suspected to involve computer security breaches turn out in the end to have a perfectly reasonable explanation. You should avoid jumping to the conclusion that you have been attacked until you have thoroughly investigated and are certain that there is no other explanation for the behavior you are seeing.
While a simple DNS cache flush is all it takes to remove the offending entry from your DNS client or server, there is a lot more to correctly handling a computer security breach than cleaning up a DNS entry and moving on. Handling a breach is complicated process, and the correct approach requires an evaluation of the level of seriousness of the attack and the value of the resources that have been compromised. If the attack was just a prank by someone who got their hands on the metasploit script, perhaps a cache flush is all you need, but a more serious incident may require a more substantial response.
Your first job is to determine exactly what has happened. If you are positive that a compromise has taken place, is that compromise ongoing? What resources were effected? Was a DNS server at your location actually the target of poisoning, or did the bad data come down from a DNS server at your ISP, requiring coordination with them? What did the attacker do once the cache was poisoned? What information did he or she obtain access to as a result?
At the very least it behooves you to determine what IP address was used to poison your cache. Typically with these attacks the record for the nameserver for the targetted domain is poisoned, allowing the attacker to control all subsequent lookups for hosts in that domain. The IP address pointed to by the nameserver record for that domain will be a host under the control of the attacker. It likely makes sense to coordinate with the ISP that hosts this address. You can use IP address whois to determine what ISP a particular IP address is associated with.
Once you've determined what occurred, the next step is to find out why. Are your DNS servers not patched? You should create a plan for mitigating the vulnerability that lead to the breach in the first place.
Frankly, a serious computer security breach should be handled by computer emergency response professionals. Response teams have highly specialized knowledge that enables them to correctly determine the true scope of a breach in spite of the myriad ways that attackers use to cover their tracks. They can quickly put a stop of ongoing attacks and help you develop an effective, comprehensive plan to recover from the damage done and prevent further abuse of your systems and networks. Furthermore, you may need to involve law enforcement, and professional incident responders can help you collect evidence in a manner consistent with legal requirements.
IBM ISS has an emergency response team standing by 24 hours a day, 7 days a week, 365 days a year. If you have been the target of an attack, you can call us at the number listed on this web page any time of day, and we can provide immediate assistance to stop attacks and help you get your network back in running order. It is our opinion that if you have been the victim of a breach you should seek the assistance of a professional response team, whether ours or someone else's.
Thanks Harlan Carvey for contributing to this report.
