DNS Cache Poisoning Update

dhammabum writes "Todays SANS internet storm handler has put up an excellent update of the DNS poisoning vulnerability currently doing the rounds. The main points are that only Windows DNS servers are vulnerable (degrees of vulnerability depending on patch level), provided you are not running an ancient version of bind. Also bind4 and bind8 do not clean poisoned caches if they receive them from a poisoned Windows DNS server but bind9 does."

Comments

Informative Links:

[TripMaster Monkey]

In the interest of promoting discussion, there is a good definition of DNS poisoning here, and a longer explanation/rant regarding DNS poisoning here.

Re:Informative Links:

[TripMaster Monkey]

Hmm...the # sign in the second link doesn't seem to work...sorry...try this link instead.

Re:Informative Links:

[Anonymous Coward]

Yes, what DJB is actually pointing out there are *bugs* in most DNS implementations, that do not exist in his djbdns package.

djbdns is, and always has been, immune to cache poisoning.

It is also simpler, much easier to use and maintain, and so much more reliable than BIND or Windows DNS. It also has never had a buffer overflow or other security problem.

If you're running another DNS package, and *especially* BIND, go to the nearest mirror and ask yourself "Why am I putting my users at risk? Why am I using badly-written software voluntarily?"

My DNS server, which I set up a while back with FreeBSD and djbdns, has never been rebooted, patched, or upgraded. It has never had a problem, and in fact dnscache has never even been *restarted* except once to increase the size of the cache. (And note that when you tell dnscache to use N bytes, that's exactly what it uses).

If you're a DNS admin, don't waste your time with bugs from the 1990's. Install djbdns and get on with life.

Re:Informative Links:

[foobsr]

The second link already seems to show white, so not exactly a replacement but perhaps an addendum.

CC.

Re:Informative Links:

[tedgyz]

Thanks for the info, but, to coin a phrase, "Where's the beef?" I went to the wiki page hoping to get a clearer understanding, but was left feeling like I had just read a Microsoft help page.

To sum up...

DNS Cache Poisoning: DNS Cache Poisoning is the process by which a DNS Server's cache is poisoned.

I'm not trying to flame. Are there more in depth explanations? Don't worry, I'm not planning on writing a DNS poison worm. :-)

Re:Informative Links:

[ldspartan]

apt-get install runit djbdns-installer
build-djbdns
dnscache-conf-fhs nobody nobody /etc/dnscache 127.0.0.1
ln -s /etc/dnscache /var/service/

Granted, not super-simple, but certainly not hard.

Re:Informative Links:

[carpe_noctem]

DJB is going to turn into the next RMS if he doesn't stop spouting at the mouth with how inferior all of his competitor's software is. Even his documentation is arrogant, for chrissakes.

And I'm sorry, but bind9 isn't that complicated. I found djbdns to be much clunkier and difficult to set up. Like all of DJB's software, it relies on retarded configuration files and bizarre notation.

Don't get me wrong here; I'm a qmail admin myself and I love it, but I dislike it when people talk about his software like it was written by Moses and God and given to mankind for all of eternity. It may be pretty stable and secure, but it lacks common usability and many features of other, traditional DNS software.

Re:Informative Links:

[Anonymous Coward]

If that DJB bloke weren't so damn arrogant, many admins would have much less of a problem with using his software.

Re:Informative Links:

[Just Some Guy]

DJB's software is distributed as source code without any "license".

Which also means that you can't distribute anything but patches even if you wanted to. Forget about making it part of an OS base distribution, or using any his the proclaimed "better" code to improve any other projects. Basically, it's a proprietary product that happens to ship with source.

Put another way, I could theoretically provide instructions for replacing Windows' HTML renderer with Gecko, but that doesn't mean that it's a Free (or even Open Source) system.

I understand your point, truly, but I just don't agree with it.

djbdns includes an AXFR server.

That doesn't do much for those who need IXFR.

Re:Informative Links:

[ThosLives]

I'm not that familiar with how DNS works (other than, "hey DNS server, give me the address for xyz.com" and it spits back either an address or "I've never heard of that"), but it appears you're saying that if I try to get an IP address for "foo.com" some DNS server will tell me I really wanted "google.com"? I don't understand how that's possible.

Or, do you mean that I send on some information like "I want foo.com and I once got it at 1.2.3.4 - is this right?" and the DNS responds with "well, I think 1.2.3.4 belongs to google.com and foo.com is at 10.9.8.7"? At that point, the way I see it, it becomes really difficult to tell what name goes with what address without some physical mechanism. And that, of course, is the whole issue of "remote security".

Re:Informative Links:

[mlyle]

He's talking about a CNAME; a CNAME is like a symbolic link for DNS. That is, if you try and look up www.foo.com, it can contain a CNAME saying that www.foo.com is an alias for www.google.com. This can be really nice, because if you have many services running on one server, you can CNAME (e.g. you could have one big host, bigserver, and CNAME www.whatever.com for multiple domains to bigserver; if bigserver's address gets changed, you only need to modify one zone file).

If a DNS server returns a CNAME record, it's supposed to return an address record for the destination server if it can; e.g. it says

www.foo.com. IN CNAME www.google.com.
www.google.com. IN A 64.233.187.99

Bad things happen if the server that hosts DNS for foo.com is malicious and returns an invalid address for www.google.com; because naïve DNS implementations would then trust foo.com's address for google.com.

Update on the Update

[Hulkster]

That SAN's report actually came out yesterday, the 7th, probably when the article was submitted ... and ISC uses UTC time for their postings. There's an update the next day (today as I write this) where ISC returns the status to Green because they understand the DNS Poisoning problem and have recommendations for people to protect themselves - although it's still an issue.

Ironically, that same update describes Comcast's nationwide problems that started last night (US Time) and says it was caused by an equipment upgrade and not related to the DNS Cache poisoning. BUT, the problem was not network connectivity, but the DHCP's DNS Servers became unavailable. Read more at DSLReports and (from first hand experience), the work-around was fairly easy which was to manually specify the DNS server, rather than use the DHCP'd one. Comcast says it was resolved about two hours ago - scroll down to the bottom of the page.

dnsmasq is vulnerable too

[Ktistec Machine]

...at least, according to this link from the lwn.net security page.

Last night...

[bhsx]

Last night I couldn't reach google, comcast.net (my GF's email[although I warn her everyday about relying on ISP-based email{lock-in and all that...}]), yahoo, and a number of other sites. Strangely, Happypenguin, slashdot and sourceforge all worked just fine. I figured it must have been dns issues and kind of assumed it was this poisonning that's been happenning. Needless to say, it was annoying as hell. Add to that; 800-comcast and 888-comcast were giving fast busy signals, so their call center was being DDOS'd by a swarm of angry customers.

From the Internet storm-in-a-teacup dept...

[Eyeball97]

From the article:

"On Windows 2000 SP3 and above, the DNS server DOES protect against DNS cache pollution by default. The registry key to protect against the poisoning is not necessary: the value is TRUE if the registry key does not exist"

In other words, many or most 2000 installations should be secure against pollution if their admins posess the slightest clue.

"Windows DNS --> forwarding to BIND4 or BIND8. Windows DNS server assumes that BIND scrubs out the poisoning attempt. BIND4 and BIND8 do NOT appear to scrub the attack. Windows DNS trusts the data and the Windows DNS cache will become poisoned."

So much for "only affects MS servers" although the article does mention, and plays down ("ancient versions") the bind4/8 vulnerabilities.
I'm left wondering how many admins have their dns servers in forwarding mode, and how many of those are forwarding to bind4/8 servers? Very few, I'd think.

It's important to note, from what I've understood of it so far, that this exploit only affects the "MS server forwarding it's requests to a bind4/8 server" scenario which I would think, would be a pretty negligible number of DNS servers?!

Another interesting thing that caught my eye, was "On Windows 2000, you should manage the DNS cache protection security setting through the DNS Management Console. On Windows 2000 below SP3, the "Secure cache against pollution" is not the default so you should enable it using the DNS Management Console.
An admin who didn't already do this is dumb beyond belief, hardly a MS problem! Blaming it on MS is akin to blaming Ford if you forget to lock the door on your car. If you're a DNS admin and didn't think to check your configuration for this very old vulnerability it's time you hung up your admin hat!

For the record, I'm no more a fan of Windows than I am of *nix - but how much you wanna bet this post'll raise 80% MS bashing comments, 10% "funny" comments, and maybe 10% useful DNS Admin comments?

Re:From the Internet storm-in-a-teacup dept...

[Anonymous Coward]

"In other words, many or most 2000 installations should be secure against pollution if their admins posess the slightest clue."

Actually, no clue needed. Win2k DNS server has since SP3 made this the default setting. Win2003 DNS server also makes this the default setting.

So, zero action is required by Windows DNS admins, unless for some reason they are running Win2k pre-SP3, or NT4. Even with these older versions of the OS, a single setting change secures the box from DNS poisoning.

Re:From the Internet storm-in-a-teacup dept...

[Anonymous Coward]

Except you are wrong. Go back and re-read the article.

WRT DNS poisoning, Windows DNS servers have been secure by default since Windows 2000 SP3. The only vulnerability exists if they are getting already poisoned data from a vulnerable server (BIND4/8) used as a forwarder.

Mod Parent Up

[Daedala]

It's an externality. The invisible hand of the market isn't going to fix things for you

link with explanations

[Anonymous Coward]

Here is a good explanation at security focus

http://www.securityfocus.com/guest/17905

Additional Bind 9 security

[Anonymous Coward]

Even if you are already running Bind 9, you should consider reading Rob Thomas' Secure BIND Template for how to best configure bind.

Djbdns - immune to DNS cache poisoning

[bad_outlook]

Djdns deserves another mention. Here's the thread that came up a few days ago on the subject. I'm running it on FreeBSD now, and have learned allot through this discussion (that hasn't happened to me on /. for a long time either, so it was pretty cool.

Previous /. THREAD

Djbdns site with a ton of good information

I like it.

bo

Simple explanation

[Otto]

DNS Poisoning is possible because of the way some DNS servers work.

When you want to lookup a site, you send a request to your DNS server, which then does the lookup and returns the results to you.

Say you need to know the address to www.yahoo.com. You ask the DNS server for it. It doesn't know, so it looks at what it does know. In the simplest case, it knows the address of the DNS server for *.com, so it asks him. He replies that he doesn't know either, but that he knows *.yahoo.com's DNS records are stored at x.x.x.x. So your DNS server goes and asks x.x.x.x. He does know where www.yahoo.com is, tells your DNS server, who then sends you back the address.

Typically, a DNS Server is running for a lot of users at once, so it improves speed by caching the results of these queries. So if you asked for www.yahoo.com again, your DNS server looks in the cache, finds that www.yahoo.com is in there, and gives you the answer right away. No need to look it up, time saved all around.

DNS Cache Poisoning is where an attacker tricks a DNS Server into caching incorrect information. This can happen by having a rogue server setup somewhere. So say the nameserver for www.badguy.com has records that say his name is also www.yahoo.com. When you lookup www.badguy.com, and get to that point, badguy.com says "hey, this is my address, and here's some other names that I'm known by: www.yahoo.com". Your DNS Server then stores all that info in his cache. Later you lookup www.yahoo.com and get back the address for www.badguy.com instead.

That's a slightly oversimplified way to explain it, but that's the gist of it. Somebody can trick your DNS server into giving back bad info. This is a critical security issue, because say they poison your cache and fool you into connecting to their server instead of, say, your bank's. They then give you a web page that looks just like your bank's does, you login as normal, and suddenly they have all your cash.

Many DNS servers are immune to this. How is simple: They don't cache stuff when badguy.com says he's also yahoo.com. They always go ask who yahoo.com is and only cache that more trustworthy answer.

However, the DNS system is setup as a hierarchy. Your DNS Server may not talk to root servers all the time, he might route all his queries through another, bigger DNS server. One of the bugs discovered here is that even if your DNS server is not vulnerable, the one just upstream of it might be, and that can propagate down to yours.

So there you go.

Re:It's all very muddy

[Vainglorious Coward]

what would it take to get aohell.com to ask lameproducts.com who shopping.yahoo.com is, and why would aohell.com even trust some unrelated site in the first place so that it could be tricked into asking?

The client *doesn't* ask the lameproducts.com DNS server about shopping.yahoo.com, it asks about something in the lameproducts.com domain (typically, prompted by an image embedded in an HTML email). The lameproducts.com DNS server sends back the answer about the request for the system in the lameproducts.com domain, but it *also* tacks on some more information about other domains for which it is not authoritative. A sensible client would simply ignore this additional information since (a) it never asked for it and (b) the information is outside the responding DNS's bailiwick. Unfortunately, there's a number of DNS caches out there that do not take a sensible approach.