Harden BIND9 Against Cache Poisoning

With phishing and pharming attacks on the rise, protecting your DNS servers from cache poisoning is more important than ever.

 By Charlie Schluting | Posted Apr 8, 2005
Page 1 of 2
Print ArticleEmail Article


Beyond the Deadline: How GDPR Will Impact Your Company's Risk and Security Profile

DNS cache poisoning has been around since 1993. The concept behind cache poisoning is to simply inject false information into a DNS server, where it will be cached. Then, when an unsuspecting user connects to, say, their bank's website, they are actually connecting to the IP address of an attacker. With phishing attacks on the rise, the DNS cache poisoning technique has many more uses in today's Internet. In this article we will examine how cache poisoning works, and also how to make sure your DNS servers aren't vulnerable.

How Is This Even Possible?
There are historically three reasons cache poisoning is possible. Back in 1993, ISC's BIND DNS server was allowing extra information to be included with replies. This means that all an attacker had to do was initiate a query, causing the vulnerable DNS server to ask the attacker's server for DNS data, and then in the response could include any malicious information they wanted to. This was, of course, a bug and fixed in a subsequent release of BIND.

The next vulnerability was in BIND 4, circa 1997. CERT advisory CA-1997-22 uncovered the fact that BIND's transaction ID numbers were sequential. Attackers could no longer simply send evil data to a DNS server, but they instead had to guess the next transaction ID, and send the data spoofing the ID. The attacker's only hurdle was to guess the IP source port of a legitimate request from the victim DNS server. This turned out to be trivial, since BIND was in the habit of using the same port over and over again for most DNS transactions. The transaction IDs were randomized to fix this problem.

Today, there still exist problems. BIND 8 and BIND 9 both have problems generating truly random transaction IDs. A transaction ID is a 16 bit number (i.e. 1-65536) that identifies a single DNS transaction. BIND 9 uses the operating system's /dev/random device, so the randomness is much better than existed in version 8. In BIND 8, utilizing the mathematical anomaly known as the "Birthday Attack," an attacker can correctly guess the transaction ID for a DNS request in less than 600 tries. Of course, this would need to be done before the real DNS server had a chance to respond. A simple denial of service attack on the real DNS server will slow it down enough to allow the attacker time to run through 600 transaction IDs. 600 packets is a trivial amount, and anyone with a broadband connection can execute this attack successfully.

All may seem hopeless at this point, but don't worry, it gets even worse: There are statistical methods to guess how likely a random number is to appear from a given random number generator. BIND 8's generator predictably churns out very similar numbers, making the amount of guessing an attacker needs to do extremely small. BIND 9, however, does a much better job. Another DNS server, djbdns, does an even better job because it randomizes the source port as well as the transaction ID.

Continued on page 2: Protecting Yourself

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter

By submitting your information, you agree that enterprisenetworkingplanet.com may send you ENTERPRISENetworkingPLANET offers via email, phone and text message, as well as email offers about other products and services that ENTERPRISENetworkingPLANET believes may be of interest to you. ENTERPRISENetworkingPLANET will process your information in accordance with the Quinstreet Privacy Policy.