Slashdot Log In
DNS Cache Poisoning Update
Posted by
Zonk
on Fri Apr 08, 2005 12:27 PM
from the trustno1 dept.
from the trustno1 dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Informative Links: (Score:5, Informative)
In the interest of promoting discussion, there is a good definition of DNS poisoning here [wikipedia.org], and a longer explanation/rant regarding DNS poisoning here [cr.yp.to].
Re:Informative Links: (Score:4, Informative)
Parent
Re:Informative Links: (Score:2, Informative)
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
Re:Informative Links: (Score:4, Interesting)
Parent
Re:Informative Links: (Score:5, Informative)
build-djbdns
dnscache-conf-fhs nobody nobody
ln -s
Granted, not super-simple, but certainly not hard.
Parent
Re:Informative Links: (Score:3, Interesting)
built-djbdns? Oh, that's right - it's not Free Software so Debian can't package it.
Something about configuring DNS. Maybe to run as "nobody", I presume. I guess we're setting up a cache directory in /etc? Something or another about localhost.
/var/what?
I'm not trying to slag on you, but those aren't exa
Re:Informative Links: (Score:4, Interesting)
That seems fairly reasonable. I don't think you're really protected from poisoning, unless "poisoning" only applies to certain kinds of DNS spoofing. Specifically, first note the exceptions to the djbdns security guarantee (emphasis mine):
Specifically, his forgery page points out that a spoofing attack based on the birthday paradox can still work... although probably tens of millions of packets are required. This page [securityfocus.com], which I think I got off slashdot before, uses the TCP sequence-number guessing tools to try to attack it. It's probably not quite as secure as djb estimates, but probably still in the millions. They don't seem to have actually run numbers for the randomized-port plus randomized-id, so it's unclear whether they actually attacked that thoroughly.
Parent
Re:Informative Links: (Score:5, Informative)
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.
Parent
Re:Informative Links: (Score:5, Insightful)
so much more reliable than BIND
I have never, not once, ever had BIND fail. I doubt I'm the best DNS admin anywhere, so I imagine it works well for a lot of other people as well.
Why am I putting my users at risk?
Because my secondary DNS servers, provided by my registrar, are out of my control. I can't install rsync on them to support the functionality that Dan left out of djbdns.
If you're a DNS admin, don't waste your time with bugs from the 1990's.
I'll agree with that. Upgrade to the most recent version of BIND and get on with life. OpenBSD's support of that policy is a pretty strong endorsement.
Parent
Re:Informative Links: (Score:3, Insightful)
There is a HUGE difference between BitKeeper and DJB's copyrighted software. DJB's software is distributed as source code without any "license". This means that you will always have the option of using, modifying and distributing patches for any released version. He can't suddenly take t
Re:Informative Links: (Score:4, Informative)
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.
Parent
Re:Informative Links: (Score:4, Insightful)
Two words: dynamic DNS.
There are a lot of little single-entry updates to some of our zones, and IXFR transmits only the changed entries to the slaves.
How come your zone files are so big, and how come you network is too slow to transfer entire zone files?
Reverse that: even though our zone files aren't terribly big, why would we want to transfer the whole thing each time? It's the difference between sending a patch file instead source tarball for every update. Isn't efficiency supposed to be a good thing, even when it's not absolutely necessary?
Parent
Re:Informative Links: (Score:2, Informative)
Re:Informative Links: (Score:3, Interesting)
Is this a poor implementation of the DNS spec, or is the DNS spec itself to blame for allowing such "poisoning" to occur?
In my experience, software issues occur for one of two reasons:
Re:Informative Links: (Score:5, Insightful)
(1) "Broken" code:.....
(2) Bad communication / misuse of code:....
You left one out:
(0) Bad Design: The code does everything you intended it to do and the users are using it properly, but you didn't think of all the possible states in which the code could find itself and decide what to do about them.
This is often lumped in with (1), but shouldn't be IMHO. It's one reason I think that comments in code are valuable (as are formal design documents) since it forces the person, or people doing the design and coding to restate their intentions in at least a couple of different ways.
I have written and worked with well written specs and they tend to reduce the number of pure coding errors by leaving less to the imagination of the coder. Well written specs can still fail to account for all possibilities however and that's a good reason to have meaningful design discussions (rather than the formally mandated ones that people attend these days in body but not mind).
There are many people today who think of themselves as ace coders. The world would do well to have more people who are design experts who don't practice coding at all. The two disciplines complement one another well.
Parent
Re:Informative Links: (Score:3, Informative)
If a DNS server returns a CNAME reco
Re:Informative Links: (Score:2, Informative)
CC.
Re:Informative Links: (Score:4, Informative)
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.
Parent
Crude and quite possibly befuddled answer (Score:2)
DJB makes a big point in his documentation for djbdns about this. I get the impression that
Re:Informative Links: (Score:2)
Simple explanation (Score:5, Informative)
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.
Parent
Re:hooooly sweet crap! (Score:2)
Same article, 2010. (Score:5, Funny)
In other news, water is wet.
Re:Same article, 2010. (Score:3, Funny)
Holy shit, I think my head just exploded.
Update on the Update (Score:5, Informative)
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 [dslreports.com] 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 [comcast.net] it was resolved about two hours ago - scroll down to the bottom of the page.
Re:Update on the Update (Score:2)
I saw DNS failures clicking on an apple.slashdot.org link yesterday evening. It too me all of 2 minutes to switch my local dhcp-provided dns information over to an already-running djbdns dnscache sitting on my fileserver. I just recently switched away from using dnscache, hoping to simplify the home network, of course, as soon as I do it, my ISP hoses their DNS.
Comcast hides constantly (Score:2)
Re:crapcast (Score:2)
Didn't know their DNS servers were so centralized.
Unfortunately Comcast is the only cable provider in town, and I had already become dissatisfied with local DSL offerings.
dnsmasq is vulnerable too (Score:5, Informative)
Y'know, people keep telling me (Score:5, Insightful)
Or then telling me, when they find out I don't use it, that I've somehow forfeited the right to complain about it anymore; or trying to hold Microsoft blameless for their security holes because the people who run Microsoft software do so by "choice" so its the users own fault, and they are just hurting themselves.
But then I keep finding that despite not using Microsoft software, I get negatively impacted by it anyway. Because the Code Red slaves on the network are bombarding me with a constant light DOS looking for that index server or whatever. Because I get bombarded with email viruses and spam from zombie PCs which, while harmless to me, make my email account less useful. Because my DNS server is running Windows.
Lovely.
So, look at this. I am being materially negatively impacted by a company whose products I don't even buy. How, exactly, is the invisible hand of the market going to help with this?
Re:Y'know, people keep telling me (Score:3, Insightful)
You need to use a visible hand to get the invisible hand to work. Put together and win a class action suit, cost them lots of money. Then the price of Windows will go up, and fewer people will use it.
Get off the network (Score:4, Insightful)
Parent
Mod Parent Up (Score:5, Informative)
Parent
Re:Y'know, people keep telling me (Score:3, Insightful)
Re:Y'know, people keep telling me (Score:4, Insightful)
The invisible hand of the market has never been any good at managing companies who damage their environment, wether it be pollution, overfishing, or zombie PCs spewing out packets. That's why we balance capitalism with rules and regulations.
Parent
Last night... (Score:5, Informative)
Comcast DNS issues coincidence? (Score:3, Interesting)
From the Internet storm-in-a-teacup dept... (Score:5, Informative)
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... (Score:5, Insightful)
Nah, It'd be like blaming Ford if they sold all cars without oil in them and had, on page 545 of the 2000 page manual, directions to add oil before use.
Sure, they tell you and it is documented, but you shouldn't have the server install insecurely by default. The default should be secure, and then you need to enable the services you need. Less user friendly, more secure - that is why it isn't adopted by MS. They made a conscious decision to make it insecure (but easier to use). That is why MS bashing is justified.
Parent
Re:From the Internet storm-in-a-teacup dept... (Score:2, Informative)
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.
Re:From the Internet storm-in-a-teacup dept... (Score:2, Informative)
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.
DNS poisoning? (Score:3, Funny)
What DNS poisoning?
Isn't this www.NerdsMeetingExcitingGirlsOnLine.org?
link with explanations (Score:4, Informative)
http://www.securityfocus.com/guest/17905 [securityfocus.com]
Additional Bind 9 security (Score:3, Informative)
Bind 4? (Score:2)
Re:Bind 4? (Score:2)
Windows is insecure by default. Also that option isn't obvious at all.
There are other reasons I won't use Windows DNS but this doesn't help...
DJB is laughing this up I'm sure (Score:2)
When will the world learn to stop using BIND?
Re:How did I KNOW??!! (Score:2)
Re:Comcast, last night all DNS servers down (Score:3, Interesting)
It has a habit of just shitting out every time my dhcp lease expires, rather than refreshing it and moving on with life, so I figured that was it, or perhaps dnsmasq (which I use to proxy for my lan) got fubared.
Eventually I just plugged my cablemodem into a windows box, since they "just work" without fighting a bunch of resolv.conf or
Re:Comcast, last night all DNS servers down (Score:3)
There is no such thing as a "good upstream DNS server". There are authoritative DNS servers and there are DNS caches (also called resolvers). The root DNS servers are authoritative only. You cannot use them to resolve DNS queries.
If you want to resolve queries you need to run a DNS cache, use your ISP's, or use one somewhere else that someone left open. Run