The DNS Bug: Why You Should Care
August 15th, 2008 by Cory Wright
It's not every day that the New York Times writes articles about the Domain Name System, but then again this DNS bug is anything but normal.
It's been over five weeks now since Dan Kaminsky first announced the major flaw that he found in the DNS protocol. Although most of the details of the bug have been public for a few weeks now, it wasn't until last week at the Black Hat and Defcon conferences in Las Vegas that Kaminsky explained the depth of the issue. As I listened to him describe the ways this bug can be exploited my heart dropped down into my stomach and I felt a little sick. My friend was only half joking when he whispered to me "I'm thinking about transferring to accounting."
Yes, the bug is that bad. Everyone should be paying attention to this one. Fortunately, most of the big sites out there have been patched, for now. But the current patch only buys us some time, it doesn't actually fix the real problem.
In case you are just joining the party, the bug that Dan found can be used by an attacker to poison DNS records. In other words, he can redirect your email, instant messages, website visits, or any other traffic that relies on DNS. Which, of course, means all traffic. Yes, that sounds scary, but it seems that most people don't fully appreciate the degree to which this can be exploited. Dan's presentation made it crystal clear.
What This Means For You
Let's start with a quote from George Kurtz, a VP at McAfee:
If you control the DNS servers, you control the Internet.
This exploit effectively grants control of the DNS servers to anyone clever enough to execute the attack. When you control DNS you also control email. And when you control email you also control, well, everything.
Email is Broken
Assume for a moment that I've used this DNS exploit to take control of your email account. The most obvious effect is that I can now read your mail. Also, I can read your mail and continue forwarding it to you, so that you never realize there is a problem. I can add attachments to your messages, or infect existing attachments from people you trust with viruses or malware. When your best friend sends a link to you about that funny video on YouTube, well, I can rewrite that link to go anywhere I want.
Of course, we all know that nobody out there uses the Internet mail system to do harm, right? Just imagine, instead of getting normal annoying spam like you've been seeing for years now, you also now have to worry about legitimate messages from your friends being the carriers of trouble.
So how else can I use email to my advantage? Kaminsky pointed out that almost every website out there relies on your email address to verify your identity. Using the whois database I can find out who the administrative contact is for, say, microsoft.com and claim that email address. Then I just browse to the website of the registrar for microsoft.com, click on the "forgot my password" link, and have the password for that account reset. Since I'm getting the email for that account, I'll also get the link they send me that says "please click here to verify your new password." At that point I effectively own microsoft.com and can do whatever I want, including changing the contact email address, or transferring it to a different registrar.
Think about that the next time you see a "Forgot my password" link on a website.
SSL is Broken
Dan Kaminsky said that many people were pointing to SSL as a safety measure. He told them they should be more cafeful. After all, how does one go about registering a SSL certificate? Anyone is allowed to buy a certificate, but they must show some authoritity over the domain. This authoritity is checked by the certificate authorities (CA) by using DNS, typically in one of three ways:
- The CA looks up the domain via whois
- The CA sends an email to an address they have on record
- The CA checks for a specially named file on the website's server
As Dan pointed out in his talk, all three of these methods rely on DNS, which we have poisoned. Just because that site you are visiting uses SSL doesn't mean it's the site you think it is. :)
The Web is Broken
Ok, so enough about email. Why else should you care? (as if that weren't enough already) Well, how many sites do you think you visit that have the following code embedded in them?
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>
<script type="text/javascript"
src="http://partner.googleadservices.com/gampad/google_service.js"></script>
<script src="http://www.google-analytics.com/urchin.js"
type="text/javascript"></script>
<script type="text/javascript">
_uacct = "UA-XXXXXXX-1";
urchinTracker();
</script>
If I were to inject poisoned records into your DNS for pagead2.googlesyndication.com, partner.googleadservices.com, or www.google-analytics.com then I can execute javascript from any website you visit that uses Google Analytics or Google Adsense. The same holds true for ad.doubleclick.net, developer.yahoo.com (YUI), or any other site that serves commonly included scripts (src="?").
Desktop Apps are Broken
Kaminsky also pointed out that we have now entered an era where the Internet has expanded to the desktop. Many applications are useless without an Internet connection, such as AIM/ICQ/Jabber/etc, iTunes, Skype and most popular games. By poisoning the DNS entry for login.oscar.aol.com I can intercept AIM messages for anyone who is using that DNS server. The same holds for any other Desktop application that connects to the Internet.
Perhaps most worriesome are mechanisms for applying automatic updates. Yes, this includes attacks on popular Linux package management systems such as apt-get and yum. But it goes beyond that, and into systems that automatically update such as iTunes, Mac OS X, Open Office, Winzip, Winamp, and others. Imagine what an attacker could accomplish if he could poison swquery.apple.com and swscan.apple.com in Comcast's DNS servers. Mac OS X, as well as iTunes, periodically checks for software updates in the background, and pops up a notification if there are upgrades to be applied. An attacker could push down any software update and the innocent user would never know the difference.
Everything Else is Broken, Too
Of course, these are just some of the reasons an attacker may want to poison DNS. Kaminsky covers many more in his presentation, including CDN population, writing SSL cookies, and discovering internal addresses for databases, backup servers, and authentication services. He specifically states that it is indeed possible to poison the top level domains, including com, net, and org. That's right, an attacker can intercept all DNS requests for .com. This means that he not only gets to respond to your questions, but also find out what questions you are asking. Those "private" DNS records are no longer private (they never were, really).
The initial patch that the vendors released on July 8th has been deployed in most places by now, but again, it is only a temporary solution. It just makes it harder for an attacker to poison DNS - it doesn't make it impossible. In fact, a Russian researcher named Evgeniy Polyakov has already demonstrated that it is possible to poison the latest patched BIND DNS server with two standard desktop PCs and a gigabit ethernet connection. Instead of 10 seconds it took him 10 hours, and required a lot of traffic.
We are still in trouble, but this is the best we have for now.
__________________________
Cory Wright is a blogger for LinuxJournal.com
Special Magazine Offer -- Free Gift with Subscription
Receive a free digital copy of Linux Journal's System Administration Special Edition as well as instant online access to current and past issues. CLICK HERE for offer
Linux Journal: delivering readers the advice and inspiration they need to get the most out of their Linux systems since 1994.
Subscribe now!
The Latest
Newsletter
Tech Tip Videos
- Nov-04-09
- Oct-29-09
- Oct-26-09
Recently Popular
From the Magazine
December 2009, #188
If last month's Infrastrucuture issue was too "big" for you then try on this month's Embedded issue. Find out how to use Player for programming mobile robots, build a humidity controller for your root cellar, find out how to reduce the boot time of your embedded system, and if you're new to embedded systems find out the basics that go into one. You can also read about the Beagle Board, the Mesh Potato and a spate of other interestingly named items. And along with our regular columns don't miss our new monthly column: Economy Size Geek.
Delicious
Digg
StumbleUpon
Reddit
Facebook








The internet isn't a safe
On August 28th, 2008 Johanna (not verified) says:
The internet isn't a safe place anymore. One can get worms and trojans from all sort of sites. I use Hughes Net as my internet provider and the guys that installed the cables were nice enough to install a firewall for me.
DNSSec
On August 21st, 2008 wisser says:
There is a solution. It is around for almost a decade but politics are stalling it. DNSSec (RFC 4033, 4034, 4035) does prevent this kind of attack. And DNSSec is working. The Swedish TLD is offering DNSSec and the major Swedish ISPs are using DNSSec in their resolvers. Of course there are problems but cache poisoning isn't one of them.
Solution is easy: DJBDNS
On August 18th, 2008 erth64net (not verified) says:
Yawn...this is old news... I, as well as my customers and end-users, have nothing to worry about. We use DJBDNS, which was hardened against this age-old attack nearly a decade ago; the DJBDNS DNS engine continues to be invulnerable to the inherent flaws of BIND's design (and its derivatives).
djbdns is indeed a great
On August 19th, 2008 Cory Wright says:
djbdns is indeed a great piece of software. See my article about it in this months issue of Linux Journal. :)
However, djbdns is not completely invulnerable to this attack. Evgeniy Polyakov has shown that even source port randomization can be defeated with enough traffic. Also, if your dnscache instances are behind a NAT device that normalizes the ports of outbound queries then you may not be protected.
__________________________Cory Wright is a blogger for LinuxJournal.com
A note about NAT device
On October 12th, 2008 Anonymous (not verified) says:
Particularly about NAT device normalizing the port, if you use OpenBSD (what else, right?) based NAT firewall, the source port will be randomly chosen and thus, it doesn't normalize the port. Now, you may ask "How random is OpenBSD randomly chosen those ports?". I don't know the answer on top of my head but you can research on it. I wouldn't worry too much about it since their random generation mechanism is used in other parts of the (well-audited) OS.
See this note in pf documentation at http://www.openbsd.org/faq/pf/nat.html,
"Source port: replaced with a randomly chosen, unused port on the gateway (for example, 53136)"
By the way, I've been using djbdns for over 2 years now and I love it. Read DJB comments that he posted at http://cr.yp.to/djbdns.html . Those made me switch to djbdns. While you are at it, check out his qmail: one of the most secure one. I'll add that I have more confidence in qmail than even Postfix just because it uses multiple processes that run under different users who don't trust each other's input (and validate it). And qmail works with ucspi-tcp. Familiar with tcp wrappers? Check out ucspi-tcp, you'll love it.
And since it was released
On August 19th, 2008 Anonymous (not verified) says:
And since it was released into the public domain in Dec. of 2007 I can't figure out why it isn't being used as the standard everywhere now.
djbdns
On August 27th, 2008 Anonymous (not verified) says:
If you forget about the NAT issue and use DJBDNS (it is solid no argument there) the DNS servers you use upstream may be poisoned. If the upstream is poisoned and you could cache the poisoned entry. You have protected yourself against a direct attack. If you do not have control of the upstream servers you can still suffer indirectly. That is what makes me nervous.
A default installation of
On August 28th, 2008 Cory Wright says:
A default installation of djbdns does not forward queries to upstream caches. The dnscache program resolves everything by itself, starting from the root servers and working its way down. It can be configured to forward queries, but by default it does not.
__________________________Cory Wright is a blogger for LinuxJournal.com
Post new comment