16th
Jul '08

DNS security and DNS cache poisoning

Click here to read more about SpamStopsHere, the e-mail security company that brings you this blog.

This month, DNS cache poisoning security vulnerabilities have been in the media quite a bit due to Dan Kaminsky’s ability to stir up media for a vulnerability that he’s researched. While DNS cache poisoning isn’t a new vulnerability, a lot of people didn’t know about it and how new attack methodologies such as cross site scripting have made it more dangerious. Although vendors are working at patching the issue, there is a lot of doubt in the security community about the severity of the actual issue due to the closed nature of Kaminsky’s research.

Although we use mnemonic names on the Internet like “spamstopshere.com”, our computers need these names translated into numeric Internet protocol addresses to actually be able to communicate. A domain name service, also known as DNS, is what looks up the current internet protocol address, also known as an IP address, of a web site or e-mail server so that your computer can find it.

The obvious security issue related to DNS is that if the hostname of the computer you’re trying to communicate with is maliciously resolved to the IP address of a criminal’s server, you may find yourself sending sensitive data to a third party that is ready to intercept it. An interoffice e-mail to your boss may end up going into the inbox of a criminal instead. You may think you’re at a bank’s web site to get their phone number, but end up at a criminal’s web site. This would be hazardous when you call the telephone number and find yourself giving your account details to a criminal.

Excluding encryption with authentication, the most important way to ensure that your data is not intercepted is making sure that it’s addressed correctly.

DNS has a known vulnerability. To be as lightweight as possible, DNS uses a connectionless protocol known as the user datagram protocol, or UDP. This protocol doesn’t initiate a connection, but rather just take turns sending information back and forth. It’s basically like using postal mail rather than a fax machine.

If your secretary sent a postal letter to your bank, asking for the bank’s phone number, it would be rather easy for a criminal to send you a forged reply, containing the criminal’s own telephone number instead. You wouldn’t know that the response letter that you received and were expecting back was actually sent to you by the criminal.

If your secretary was accustomed to requesting contact information updates, one thing that would be suspicious would be to receive an update that wasn’t a response to a request. In the DNS system, unrequested updates would be discarded, so let’s assume that your secretary does the same thing.

Therefore, for the criminal to sneak in his reply, he would first need to know that you had sent out a request. One way to do this would be for the criminal to intercept your request. However an often easier way would be for the criminal to call your secretary as an office directory user and ask your secretary to update the contact information for the bank.

Let’s also assume that your secretary sends out update requests once a week for everyone in your directory. Another tactic used by criminals may then simply involve bombarding your secretary with contact information updates for specific common vendors, hoping that a request had been sent out recently.

Your secretary may notice that he’s having problems keeping responses straight. To solve this, the secretary may start putting a three digit number in the requests and ask the respondent to include the same number to be used to verify and match up the responses.

The criminals may catch on and start sending forged responses with every possible three digit number in them. Far fewer responses would be needed if the secretary used a predictable sequence of numbers. However, in order for the criminal to even get a couple samples of the requests going out, in order to see if there was a predictable sequence, he would need to intercept them. One trick the criminal could use would be to ask the secretary to send a couple update requests to the criminal himself.

This is basically how the DNS system works, and how criminals are substituting their own addresses to intercept communications. A DNS resolver is much more at risk if you allow the public to use it to resolve names, because you’re basically opening up the can of worms where the criminal is allowed to ask your secretary to send out an update request. Having a public resolver allows the criminal not only to predict when the requests are going out, but also get samples of the requests to determine if a predictable sequence is being used for the authentication codes.

Some people in the security community believe that the DNS vulnerability that Kaminsky will finally reveal at the Black Hat security conference on August 6 will simply be this known DNS cache poisoning vulnerability combined with cross site scripting attacks. Due to cross site scripting attacks, a criminal could partially control what queries a user of a private DNS server would make, therefore getting the same benefits of it being a public DNS caching server. If it’s true, it’s just odd that Kaminsky was able to stir up this much response out of software vendors to finally take this issue seriously. Some are angry about Kaminsky coming along and taking credit for this known vulnerabilty by getting people to take it seriously. Even if there is no new vulnerability, perhaps he should get the credit for driving the change. We won’t know for sure until August, what exactly is going on. I would recommend updating any caching DNS servers before then, just in case.

UPDATE: I don’t know how I missed this source earlier, but Dan Kaminsky was nice enough to stop by and leave a comment below indicating that people’s viewpoints regarding his research are changing toward the positive. People are still of course trying to guess what the exact vulnerability is. I look forward to hearing about the vulnerability next month. It’s likely to be something that I would never have thought of.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

One Response to “DNS security and DNS cache poisoning”

  1. Dan Kaminsky says:

    I called up Tom Ptacek and laid it out for him. He’s retracted his statements — in his defense, he asked me point blank what the story was, and I refused to tell him. So I’m OK with what went down, and think Tom’s awesome for owning up once he heard what the bug was.

    http://www.matasano.com/log/1093/patch-your-non-djbdns-server-now-dan-was-right-i-was-wrong/#comments

Leave a Reply