Can you trust your Domain Name Servers?

DNS Spoofability? Huh?

Near the middle of 2008, the world was informed of the existence of a recently discovered, previously unknown and very serious vulnerability that was present within the majority of the Internet's domain name system (DNS) servers. The vulnerability was considered critical because, if exploited, it could be used to redirect unsuspecting Internet users to malicious web sites without detection.

You and your web browser would believe you were at your banking site.

You entered the URL correctly, or used a reliable link or shortcut. Everything

would look right. But you would be logged onto a malicious foreign web site

which was ready and able to capture your private banking information.

During the initial disclosure, the public was not told anything about what the problem was, only that there was one, that it was bad, and that the entire Internet world now had just four weeks to patch and update all existing “DNS nameservers” . . . because full details of the newly discovered vulnerability would be disclosed during the forthcoming Black Hat conference by Dan Kaminsky, the security researcher who had discovered the vulnerability and the means for exploiting it.

Despite the way that sounds, Dan is not one of the “bad guys.” He's a well known, reputable and respected security researcher who had already been working—in the strictest of secrecy—for many months with every major DNS server vendor. He had been explaining and demonstrating the problem he had discovered and working with them to get their servers ready to be updated.

The news was deliberately sprung upon the unsuspecting world because Dan and the DNS vendors knew that mischievous and truly malicious bad guys alike would find this revelation far too tempting to pass up and would jump on the news immediately in an attempt to figure out how to take advantage of this juicy new and significant critical vulnerability. And indeed they did . . .

Weeks before Dan's planned Black Hat conference

disclosure, good and bad hackers had worked out

the details of Dan's discovery and were actively

exploiting the newfound vulnerability.

Dan's plan was to keep the whole problem a secret until all DNS server vendors had updated their code and were ready to deploy their new versions onto the Internet together. Only by doing that would “the window of exploitation opportunity” be kept as narrow as possible. And that's what happened . . . more or less . . . and it is the “less” that is the reason for these pages, and for our development of the comprehensive DNS test you are about to run:

There are approximately 11,900,000 DNS nameservers in

the world, on the Internet. And even today many of

them have still not been updated to prevent the

exploitation of this serious vulnerability.

What exactly is the vulnerability?

As you will see from the samples of DNS nameservers our users have tested many months after everything was supposed to be fixed, serious problems remain. So the question is: have all of the DNS servers YOU are currently using been updated? Is YOUR use of the Internet safe? Or might it be subject to this well known and now readily preventable vulnerability?

The “DNS” or “Domain Name system” converts easy-to-remember, mostly alphabetic “brand name” URL domain names such as GRC.COM, AMAZON.COM, EBAY.COM, GOOGLE.COM, into their corresponding much-less-friendly Internet IP addresses. For example, GRC's domain name of WWW.GRC.COM has the corresponding IP address of [4.79.142.202]. That numerical address is what Internet applications such as web browsers, eMail, instant messaging, and everything else actually use to converse across the Internet. DNS allows us to refer to remote Internet objects by their much easier to use name rather than by their IP address number. But imagine if that dictionary lookup process, of converting names to numbers, were deliberately corrupted.

What Dan Kaminsky discovered was a reliable, quick and efficient

way for malicious hackers to deliberately change the Internet

IP addresses of any web sites to whatever they wanted.

When Dan demonstrated this to the DNS vendors, they were terrified, because they knew the Internet depended upon DNS for its operation, and this flaw represented a huge vulnerability and opportunity both for mischief and for malicious exploitation.

The attack is known as “Cache Poisoning”, and although it has been understood to be a theoretical problem for many years, it was never believed to be a serious vulnerability until Dan discovered how to do it quickly and easily.

It is definitely not necessary for you to understand the fine details of the attack in order to determine whether your DNS servers might still be vulnerable — we've made that easy and automatic for you. But if you are interested in learning more — either before or after you test your own DNS servers — Leo Laporte and I describe the entire scenario in detail during our 103-minute “Security Now!” audio podcast (#155). Since it is a standard mp3 audio file, you can freely and easily listen to any or all of it, or read the corresponding textual transcripts:

Additionally, the “How This Works” page of these DNS spoofability pages, contains additional details about the exact nature of the DNS spoofability problem.

You can also jump to our main Security Now! index web page to peruse all previous and subsequent podcasts. We produce a new one each and every week.

Testing >>YOUR<< DNS Spoofability . . .

Performing our DNS Nameserver Spoofability test is as simple as pressing a single button (located near the bottom of this page).

However, you should be aware of a few things — such as the test's running time, the fact that your Internet router might crash, and that there are variations of the test available. So PLEASE take another few moments to read and consider the following points before you proceed to click the button near the bottom of the page:

A few important notes before you proceed Running Time: Depending upon your connection speed and the number of nameservers discovered, the total running time for this test can range from several seconds to several minutes. While the test is underway, progress dots and information are continuously displayed.

Depending upon your connection speed and the number of nameservers discovered, the total running time for this test can range from several seconds to several minutes. While the test is underway, progress dots and information are continuously displayed. Router Crashing: During the extensive pre-release testing of this system, we discovered that some consumer NAT routers were surprisingly unstable and were being crashed by running this test. If this should happen to you please consider the following: This is an uncommon but known-to-be-possible event which never results in any permanent damage to the router or other equipment. Some routers reboot themselves and restore their service, others “hang” and need to be powered off for a moment then powered back on. The final design of this test was tempered in a deliberate compromise to minimize the occurrence of router crashing while providing sufficient testing strength for everyone. A serious concern raised by our ability to crash users' routers with this entirely harmless DNS testing is that this instability may indicate the presence of a previously unknown remotely exploitable vulnerability that could potentially allow a remote attacker to gain access to your private network. The following consumer routers have been found to be crashable (in all cases the latest available router firmware was being used): 3Com 3CR858-91 OfficeConnect Ethernet Broadband Router 3Com 3CRWDR100A-72 OfficeConnect ADSL Wireless 11g Firewall Router A-Link RR24AP(i+) with latest firmware at time of crash report Belkin F5D7234-4 v3 (01) Wireless G Router (firmware 3.00.3) Belkin F5D7234-4 v4 (01) Firmware v4.00.05 Belkin F5D7630-4A (rebranded as MicraDigital) Belkin F5D8236-4 v2 Wireless N Router Belkin F5D8636-4 v2 Wireless N Router Belkin F7D2301 v1 (01) Wireless N Router Ozenda AR4505GW Philips SNA6500 ADSL Wireless Base Station Siemens Gigaset SX551 WLAN DSL To address this issue we provide two additional tests: A specially designed “Router Crash Test” that will crash any crashable router we have ever encountered. You can use this test to verify that your router is definitely not crashable (as you certainly don't want it to be). If your router is crashable you can work with your router vendor, pointing them to this test to demonstrate this worrisome potential vulnerability and induce them to update their defective firmware. Note: If your router is crashable and is not already on the list above, PLEASE drop a note to us on our DNS Test Feedback page to let us know so that we can add your router to the list above. The more attention we can bring to defective routers the more chance of getting them repaired. A “fully customizable” user-parameterized test that will allow you to experiment with all of the many test-design parameters to determine the “crashing boundary conditions” for your own router, if any.

During the extensive pre-release testing of this system, we discovered that some consumer NAT routers were surprisingly unstable and were being crashed by running this test. If this should happen to you please consider the following: DNS Benchmarking: In addition to determining the spoofability of your DNS nameservers, GRC's free “DNS Benchmark” utility can test, compare and rank the name resolution performance of any DNS nameservers accessible to you. Check it out!

In addition to determining the spoofability of your DNS nameservers, GRC's free “DNS Benchmark” utility can test, compare and rank the name resolution performance of any DNS nameservers accessible to you. Check it out! FAQ: If you have any questions or concerns please see our Frequently Asked Questions (FAQ) page where you will likely find an answer.

If you have any questions or concerns please see our Frequently Asked Questions (FAQ) page where you will likely find an answer. Feedback: If you have any questions or concerns not addressed by our FAQ page, you are invited to submit your question to our DNS Test Feedback page where it will come to our attention.

Once you have read and considered all of the foregoing, the button below will

initiate a comprehensive analysis of your currently configured DNS resolving

nameservers to determine their susceptibility to Kaminsky-style spoofing:



