DNS Cache Poisoning - Are You At Risk?

70 comments

Are you open for DNS Cache Poisoning? Are your SERPs (Search Engine Results Pages) being redirected because an attacker has compromised your DNS and is now stealing your traffic? And possibly destroying your domain in the process?

Yes you are! A recent (2006-04-09) WebmasterWorld Home Page topic discussing how one's links in the SERPs have been hijacked and are being redirected to questionable websites proves that DNS Cache Poisoning is a severe threat to search engine marketers and website owners around the world.

Links Hijacked in Search Engines
http://www.webmasterworld.com/forum5/7481.htm

We've got a section at the SEO Consultants Directory on the DNS Cache Poisoning and DNS Recursion issues here...

http://www.seoconsultants.com/tools/dns/
http://www.seoconsultants.com/tools/dns/recursion/
http://www.seoconsultants.com/tools/dns/cache/

I think this is important enough to start spreading the word as rapidly as possible. Bloggers, forum moderators, administrators, etc. We need to get the word out there so the server administrators of the world can close this big gaping hole called DNS Recursion.

Comments

No!

I'm not. In fact, I checked 30 random domains after the ones that concerned me checked out, and they all passed. Yeah, I know, not a big sample, but are you sure this isn't a chicken little warning? ;)

HaCk3rz Rul3!

Checked 100 now. Got one with two warnings, and one that could be poisoned. 1. Checking more now.

Might as well link directly

Might as well link directly to the tool instead of through some third party site.

My servers hosted by servermatrix/theplanet were open to this by default. A simple change to /etc/named.conf followed by a restart to bind and I'm fine now.

It's a Severe Threat to All of Us!

Quote:
I'm not. In fact, I checked 30 random domains after the ones that concerned me checked out, and they all passed. Yeah, I know, not a big sample, but are you sure this isn't a chicken little warning? ;)

I'm positive DG. I've been reading documents on this for the past week. This is a very serious threat and I do believe some will find that it may be a problem that exists with their website(s).

PPC Hijacking

Read this document from LURHQ Security Systems...

http://www.lurhq.com/ppc-hijack.html

Read the entire document and look at the proven examples provided. They have screenshots, header responses, etc. Then look who the subject is of their test which was done in 2005 April.

Quote:
At the heart of the pay-per-click model is findwhat.com. While it is a legitimate enterprise itself, it is the entity that pays the affiliates who are actively employing trojans and dns cache poisoning to drive traffic to the advertisers. FindWhat has a policy prohibiting certain activities of this type, and will likely terminate any affiliate account reported to them for abuse. However, terminating the account only means that FindWhat benefits from the hijacker's activity without having to pay the hijacking affiliate. It's a win-win situation for them. FindWhat's estimated earnings for 2004 were between $167.5 and $179.5 million dollars. There is no way to determine how much of that revenue was generated by traffic from hijacked machines.
Quote:
Checked 100 now. Got one with two warnings, and one that could be poisoned. 1. Checking more now.

Please do report back with your findings. The research I'm reading, much of it from US-CERT, indicates that 75% of the servers (1.3 million polled) out there are open for DNS Recursion. The DNS Cache Poisoning is just one of the exploits that can be done when allowing for DNS Recursion. And, there appear to be an alarming number of BIG hosts that have this problem and don't want to fix it.

Quote:
Might as well link directly to the tool instead of through some third party site.

Some third party site? Gee thanks! Coming from some third party poster, I'll take that as a compliment. If you're going to link, at least provide a link that is visible for printing... ;)

Run a DNS Report Now!
http://www.dnsreport.com/

Quote:
My servers hosted by servermatrix/theplanet were open to this by default. A simple change to /etc/named.conf followed by a restart to bind and I'm fine now.

For some, it may be as simple as that. For others, it won't be. Why? Because they've taken shortcuts along the way and would have to make some financial investments to correct this major potential threat.

All Windows Servers prior to 2003 were set by default to allow DNS Recursion. All Apache Servers prior to 2.1.6 have a similar problem, not technically called cache poisoning, Apache refer to it as HTTP Request Smuggling. If you perform searches online for DNS Cache Poisoning, HTTP Request Smuggling, DNS Cache Pollution, you'll find a plethora of topics from various security firms, the government, along with major voices in the industry, etc.

This is a growing concern and is something that has been prevalent for years. It is just now becoming more mainstream as I do believe some of the issues we see discussed at various fora and blogs are related to DNS issues. I learned a couple of years ago that running that DNS Report will reveal problems that can wreak havoc on your search marketing campaigns, particulary PPC as I believe this is where it is more rampant.

In my research, I discovered that this particular exploit, DNS Cache Poisoning, may be responsible for a percentage of click fraud. Man, freakin light bulb went off and then someone smacked me upside the head!

Quote:
2006-03-30 - v2.0 Update (.pdf)
http://www.us-cert.gov/reading_room/DNS-recursion033006.pdf

US-CERT is encouraging wide dissemination of this paper and organizations that currently have DNS recursion enabled are encouraged to disable it if possible.

Not wanting to rain on your parade...but

Isn't the problem with the Cache Poisoning that you mention to do with ISP DNS caching and that being poisoned, rather than the individual website DNS servers?

At least, that's what I understood the articles to mean and it makes logical sense to me.

If that is the case, while it may well be laudable for people to tighten up their site DNS for other reasons that you mention, it is not going to have the slightest effect on Cache Poisoning exploits for their own sites, since the poisoning exploits are taking place on third-party ISP servers like "Podunk Internet Providers".

Or am I missing something here?

again?

Didn't we just cover this? And wasn't that coverage also several years old? This sounds like serious chicken little, or a meme that made it all the way back around to TW (god I hate that "m" word).

Chicken Little?

What the hell is serious chicken little? Please, read the documentation. Or, if you don't have the time to take this seriously, at least read the pdf from US-CERT which was updated by them on 30 March 2006. Ummm, that's less than two weeks ago. Serious Chicken Little you say? Also, look at the rise in DNS Recursion attacks in the past 12-18 months, particularly in the past 90-120 days. It is picking up speed and now would be the time to make sure your servers pass the tests.

Yes, this has been around for quite some time, years and years. I actually had someone (well known in the industry) who proved to me that this is possible. They hijacked my DNS. On 2002/05/20 at 17:34 the switch took place. I'll never forget that day. :)

The issue we are faced with now is that people are exploiting the DNS Recursion issue. Not only people, but teams of people, companies. Read the report from LURHQ Security Systems on PPC Hijacking. Look who is involved with this.

DNS Cache Poisoning is one of the many effects that can happen if your servers allow DNS recursion. Yes, there was a topic on DNS Recursion which was the eye opener for some. This topic on DNS Cache Poisoning takes it one step further. There will be others I'm sure as more and more people find themselves a victim of this type of technical foul play. I've read the documents, hundreds and hundreds of pages, hours upon hours. I've been assimilating as much information as I can on a daily basis and learning something new each day. This is stuff you typically don't see discussed at the SEM fora/blogs. But, take a trip into Security land and they've been warning us about this for years.

Why haven't the DNS Server Administrators of the world addressed this? Why are there 75% of 1.3 million servers polled that allow for DNS Recursion? Are you aware of the potential threat if someone really exploited what they have available to them?

Here, take your chicken little comments to Ken Silva, the chief security officer for VeriSign Inc. who said this in 2006 March...

Quote:
Silva said the attacks earlier this year used only about 6 percent of the more than 1 million name servers across the Internet to flood victim networks. Still, the attacks in some cases exceeded 8 gigabits per second, indicating a remarkably powerful electronic assault.

"This would be the Katrina of Internet storms," Silva said.

Chicken little eh? I guess some people will just have to sit back and wait for something to happen before they begin to think proactively instead of reactively. It never fails, we're a tough lot. We need to make the mistakes first and then learn from them. Sorry, I changed that method of thinking years ago. I'd rather take a more proactive approach to my marketing campaigns. Domain expiration dates and DNS Issues are first on the checklist. You can probably tie in many topics at the fora to DNS issues of some sort. Many just don't think about it. They are too focused on what they see, not what they can't see.

So, being the freakin' chicken little that I am, I thought I would share this with my peers in hopes that you will help spread the word. If it doesn't affect you, great! But, maybe it affects a friend, a collegue, or business partner? How about a client? We have a fairly large voice in this matter and we can probably start the ball rolling and help clean up some of the mess out there. Use your blogging prowess and spread the word. If your server allows DNS Recursion (you fail the DNS Report for Open DNS Servers), then you are at high risk. You may also find yourself in a situation where your server is used for DDoS Attacks.

Did you read the topic at WebmasterWorld? Poor guy got jacked and that was within the last 60-90 days. Does that qualify for the chicken little title? How about the guy who got rejected for AdSense and the Google response stated it was due to a virus. Are you aware that one of the effects of DNS Cache Poisoning is the redirection to malware/spyware/adware sites? It's pretty deep. I don't think chicken little would venture into this territory. :0

Quote:
Isn't the problem with the Cache Poisoning that you mention to do with ISP DNS caching and that being poisoned, rather than the individual website DNS servers?

No. It has to do with all servers that allow DNS Recursion for non-authoritative requests.

Quote:
Podunk Internet Providers

lol! Tell that to Pair.com. They have a timeline in place now to correct their recursive DNS issues by the end of this month. I guess we can call them chicken little too, eh?

Surprised at the responses so far...

I would have thought that TWers would have been all over this and taking the necessary steps to get things in order. I never would have thought that people would try to downplay this. Not after all the official documentation provided, quotes from top security experts, etc. What's it gonna take for some of you to see the light? How about if I smack you upside the head with the same frying pan that hit me after I got involved with the DNS Recursion issues? That will probably help clear up a few things.

For all those TW readers following along, please, do me a favor. Run the DNS Report on your domain.

http://www.dnsreport.com/

If you don't fail for the Open DNS Servers, then this probably won't concern you. Unless of course the bulk of your traffic is coming from a network that does allow DNS recursion. Oh-oh, didn't think about that, did ya? Seriously folks, if you fail the test, get a note off to your provider ASAP and let them know that they need to fix it today. Not tomorrow. Not next week. But today! If they come back and tell you that it doesn't concern them and they won't fix it, then begin researching a new host immediately. You'll want to be away from that network as quickly as you can.

Sounds high?

Quote:
Sounds high, really high. Stats and all, especially when fear is involved, make me suspicious.

Okay, so let's cut that number in half. Even at 37.5%, that is a major concern.

Quote:
Yeah, but it was a Luddite Convention, at which, only two Internet marketers were present...

Yup, and one of those marketers had over 1,000 sites out there that were poisoned, some of them Fortune 500. ;)

The Sky Is Indeed Falling

Sorry P1R, but the louder people scream, the less I hear. ;)

>>The research I'm reading, much of it from US-CERT, indicates that 75% of the servers

Sounds high, really high. Stats and all, especially when fear is involved, make me suspicious.

50% of all Internet marketers in a recent poll of several thousand convention attendees had their DNS poisoned. Sounds ominous doesn't it?

Yeah, but it was a Luddite Convention, at which, only two Internet marketers were present...

I just want to know

how to poison a few competitors, but every site I checked passed.

Thanks from here P1R

Agree with p1r. It's a bit rehashed, but the reminder needs to go out until everyone here passes. AFAIK, this exploit is like a hurricane. Risk is low, but damage could be extremely high if it comes through.

Plus, I for one don't want to be part of a ddos or any hijinks. Prefer my servers locked down tight, and appreciate the reminder.

Step by Step Instructions for Poisoning a Competitor's DNS Cache

Quote:
How to poison a few competitors?

Oh, I'm sure there are one or two here who could give you step by step instructions. Definitely not something you want to talk about at the public level. ;)

check wiki

wiki has some super good docs on this

http://en.wikipedia.org/wiki/DNS_cache_poisoning

Podunk != Pair

Unless of course the bulk of your traffic is coming from a network that does allow DNS recursion. Oh-oh, didn't think about that, did ya?

Actually, I did think about it and it was the point of my previous post, but you seem to have a failure in comprehension.

The valid point about correcting DNS recursion doesn't benefit from your misleading arguments about DNS cache poisoning.

Q. If you make the changes you recommend, can visitors to your domain (for example, hosted at Pair) still be hijacked in the cache of another ISP (for example, for all customers of Podunk Internet Services)?
A. Yes

So yes, making the change you recommend is "a good thing"; yes, if we all did it it would be "a better thing"; and no, it has no practical short-term effect on what you are talking about.

Read one of the sources you recommend:

In this scenario, an attacker tries to intercept secure communication between two parties. For example, Xavier wants to make an online purchase at Yuri's website. The attacker poisons the cache at Xavier's ISP, pointing traffic to Yuri's site to Zamfir's system. Zamfir accepts the incoming SSL connection, decrypts it, reads all the traffic, and makes the same request via SSL to Yuri's site. Replies from Yuri are read by Zamfir then sent back to Xavier over the same encrypted session. Zamfir now has Xavier's credit card number and all other details needed to make illicit use of it.

Domain Name: MATTCUTTS.COM

Domain Name: MATTCUTTS.COM
Registrar: GANDI
Whois Server: whois.gandi.net
Referral URL: http://www.gandi.net
Name Server: NS176.PAIR.COM

/me injects pair dns for mattcutts.com to redirect =P

The Poisoned List

Okay, Chicken Little is back and here's the DNS Cache Poisoned Blacklist...

http://dns.measurement-factory.com/surveys/200603-poison.txt

BTW, the above surveys are run every month.

Did you know that there is a blacklist out there that is being referenced. And, if you are on that blacklist there may be major issues to contend with?

Cluck, cluck, cluck...

stever, I'm going to guess that your level of expertise in this is far greater than mine. I'm new to this. So, are you saying that this isn't a problem? Or, that I have my information mixed up?

BTW, my new nic is Chicken_Little and I do have a Tin Hat in my collection. ;)

the list not to be on....

the list not to be on....

What If?

And this is definitely Chicken_Little but, what if the search engines (spiders) perform some sort of DNS test to determine if they are in a safe environment? What if they reference this same blacklist that is being circulated by those who perform the tests? What if? What if? These are all questions I've been writing down and then researching further. Since I'm on Spring Break, I might as well do something productive with my time, eh? What better things can I do than stir up some schit at TW? :)

stir up some what?

I am oddly reminded of a UFO "info" website. Not sure why; the thought just crossed my mind. Anyway...

What about ARP cache poisoning? Oh, and then there's that little CISCO router exploit that has been in existence for what, 2 years? OMG think of how many CISCO routers are running the worlds networks! Wide open for phishing attacks! Regimes are at risk! And then there are those IE openings, and all those unpatched Windows servers. Oh, and the SSLv1 servers. And on and on and on.

C'mon enough already. If the world had jumped at the chance to clamp down on open relays back in 2000 a huge portion of the world's wealth would never have been generated (including a significant portion of the collective wealth of TW members, I suppose) and we wouldn't have the good spam laws we have now.

When it matters it will be addressed (and it already has been addressed incrementally over the past 2 years as I stated earlier and earlier). So now you did yours. Good for you. It sounds like Pair is already working on it (you might ask your favorite shared host if they jailed their shared hosting properly while you're inquiring...might be about time to fix that one, too).

Disclaimer: I don't use Pair nor have I ever used Pair. I am not aware of Pair having sub-optimally configured their shared hosting environment such that source code may be exposed to competitors, and I don't mean to imply such. As with all exercise programs, you are strongly advised to consult a professional before engaging in these exercises.

oh, so the discussion is continued here ....

(nods to stever and pageoneresults)

I ignored the first thread on WMW, but clicked on the second one in the early hours looking for something to read. Had to come out of lurk mode over there and try to clear some things up.

the reply went like this:

As I understand it, the premise of this thread is that:

the dns for a domain is subject to highjack if the authoritative name servers for the domain permit recursion.

I think this is untrue and here is why:

the domain dns highjacking actually occurs at, is targetted at, the dns servers of consumer isp's. for example, the AOL dns servers responding to the dns requests originating from AOL subscribers. the goal of the poisoning is cause these AOL dns servers to *bypass* the authoritative name server for a domain. thus, poisoning of the authoritative name server, that is, *your* name server is a non-issue, or at least a separate issue. in fact, an authoritative name server does no upstream lookups when replying for it's own zones. the links posted earlier to the various informational articles are quite clear on this if read carefully.

the only thing that is going to happen if the cache of *your* authoritative dns server gets poisoned is that outgoing email might be misdirected, or if you are in the habit of using them from your workstation as client dns settings, then your browser or ftp client might get highjacked. in other words, at the most, you risk trying to ftp proprietary source code to the wrong box.

i realise that i am posting at the very tail end of the thread, but i hope it gets read by those who have become worried by the alarms that have been raised.

the bottomline is that if your authoritative dns is working well, then there is no reason to change it. the problem is downstream from you. i am quite surprised that the tech staff of various hosting companies have not pointed this out.

The last thing I posted there was:

But, but, but ...

the scope in the context of the audience here ought to be:

what *can* and *should* the webmaster do directly that affects
the outcome with regards to recursion and cache poisoning

this does not automatically preclude permitting recursion on your dns server.

thus for dns servers *under our own control*, we have:

1. ensure that the proper dns records are in place
2. prevent unauthorised modification of same

cache poisoning can still affect your visitors, but it outside of your *direct* control.

It *is* really that simple.

beyond this, you really have to look to dns servers under someone else's control.

Oh, about Microsoft Knowledgebase Article Q241352, it only applies to pre Windows 2000 SP3 and NT4. Even so, it is an available fix that only involves registry settings. Unlike some other dns software where a complete replacement is required. No need to keep on pointing the finger only at Microsoft products.

Anyways, I wrote a more detailed piece which can be found at:

dns cache poisoning

It emphasises that there are lots of ways to screw up on authoritative
dns name servers. Cache poisoning is not one of them. Hopefully, this
will come as a relief to those webmasters who have come to believe
otherwise ... and the poor overworked tech staff at their hosting
companies.

It needs a little link love :)

nice job plum

you got some link love :-)

Not exactly

DNS poisoning, but too often we feel secure about our ISP/hosting security when we shouldn't.

http://www.pcworld.com/news/article/0,aid,125263,00.asp

Excellent Link!

Great link Kirby, thanks for posting that. This is actually something I am in discussion with SANS on right now. When I first posted my original information on DNS Cache Poisoning, I may have had a slight misunderstanding of what was happening. I'm in the process now of correcting my errors and at the same time presenting theories to those concerned based on our industry. Much of the testing and research being done is at the large scale end. I do believe that those downstream, at the local level, are being subjected to various exploits that they would probably never know about. :(

Part of what I'm researching right now...

The below is right in line with the above. I presented a theory to SANS and the response I received is below.

Quote:
There are two methods that I know to dynamically update DNS information on an authoritative DNS server. This isn't technically cache poisoning, it's more of a feature that has been specifically enabled. There are two ways of doing this:

1) Using part of the DNS specification that allows remote machines to update DNS entries for their zones. If I understand correctly, this is how Windows clients can add themselves as hosts into Active Directory DNS. Most externally facing DNS servers should have this disabled. But if it's enabled, an attacker could selectively modify DNS entries. Read the main page for "nsupdate": http://www.die.net/doc/linux/man/man8/nsupdate.8.html

2) If the DNS provider allows for dynamic DNS in a method similar to dyndns.org or other DNS registrars. Usually, the end user has a username/password that is sent to the DNS provider. If an attacker gets this authentication information, then the attacker would be able to change information for that zone at will.

I'm also working with a firm to develop a public tool to test a server for this type of exploit. I'll be sure to keep you posted on our progress. :)

my nits about molehills ....

First, thanks John!

now, on to business ...

From the PCWORLD quote:

Earlier this month, attackers were able to hack servers run by the Internet service provider that hosted the three banks' Web sites. They then redirected traffic from the legitimate Web sites to a bogus server, designed to resemble the banking sites,

...

Premier Bank, Wakulla Bank, and Capital City Bank, all small regional banks based in Florida.

Has nothing to do with DNS, and has everything to do with 3 small local banks having no business being on the internet. Insecure servers being targets of opportunity are old news. Older than the internet.

From the quoted reply from SANS.ORG:

I presented a theory to SANS and the response I received is below.

There are two methods that I know to dynamically update DNS information on an authoritative DNS server. This isn't technically cache poisoning, it's more of a feature that has been specifically enabled. There are two ways of doing this:

1) Using part of the DNS specification that allows remote machines to update DNS entries for their zones. If I understand correctly, this is how Windows clients can add themselves as hosts into Active Directory DNS. Most externally facing DNS servers should have this disabled. But if it's enabled, an attacker could selectively modify DNS entries. Read the main page for "nsupdate": http://www.die.net/doc/linux/man/man8/nsupdate.8.html

2) If the DNS provider allows for dynamic DNS in a method similar to dyndns.org or other DNS registrars. Usually, the end user has a username/password that is sent to the DNS provider. If an attacker gets this authentication information, then the attacker would be able to change information for that zone at will.

So, it's not technically cache poisoning. As a matter of fact it's not cache poisoning at all. As for dyndns, et al, the tld servers would have to delegate to dyndns as the name servers for the domain in question. Everyone one running with their commercial domains, please raise your hands. No one? Thought so.

For context, exactly what theory was presented to SANS to elicit this response anyways?

From RFC 2136:

Dynamic update is enabled on a zone-by-zone basis, by including an allow-update or update-policy clause in the zone statement.

While RFC2136 contains recommendations but no requirements for security, note the above quote from the Bind 9.3 admin manual. Even in the stock configuration, you have to load the bullet and pull the trigger before shooting yourself in the foot. If the admin is that lame, you might as well put him out of his misery... and hire a pro.

I think I said

that it wasnt DNS poisoning, but just sloppy security. The DNS issue, where it exists, is basically just sloppiness, is it not?

dns!=hacking

Yep, you did.

Look at the post below yours though.

Moved to WebmasterWorld

Okay, instead of trying to cover this at two places, I'm going to continue with my coverage at WebmasterWorld. stever, plumsauce, digitalghost, I've provided more than enough documentation on this at WebmasterWorld to hopefuly convince those who have control over this to make the necessary changes. You can't continue to try and dispell this when Internet security firms, top security researchers, etc. are all warning to fix this now. For those of you interested in following along, I've provided recent documentation to support all of what I'm saying. And, that documentation comes from the authorities on DNS.

Here's the topic that started it all. It was posted on 2006-03-13 at WebmasterWorld.

DNS Recursion - Open DNS Servers
The new open relay problem. Are you addressing this?
http://www.webmasterworld.com/forum23/4488.htm

These next two topics were spawned as one of the exploits that can happen when you allow for non-authoritative DNS queries. Exploits such as DNS Cache Poisoning. The cache poisoning then leads to all sorts of other technical foul play. And where does a good percentage of it lead to? The affiliate space and what researcher's refer to as rogue affiliates and/or miscreants. FindWhat/Miva appear to be the target of investigation as evidenced in the LURHQ Security Systems document.

http://www.lurhq.com/ppc-hijack.html

By the way, much of this is new (specific attacks) and researchers are implying that it is a severe threat. Especially when you have this many servers out there that are in this sorry state...

Quote:
2005 August - "There are about 9 million DNS servers on the Internet, Kaminsky said. Using a high bandwidth connection provided by Prolexic Technologies, he examined 2.5 million. Of those, 230,000 were identified as potentially vulnerable, 60,000 are very likely to be open to this specific type of attack, and 13,000 have a cache that can definitely be poisoned."

DNS Cache Poisoning
Redirecting web traffic through cache poisoning.
http://www.webmasterworld.com/forum23/4545.htm

PPC Hijacking
Is your hard earned and paid traffic being redirected?
http://www.webmasterworld.com/forum85/1313.htm

You mean you want me to subscribe to WMW...

...just for this?

Or is that not really necessary? :-)

Or is that not really necessary?

No, these are publicly available topics, they are not in the Subscriber's forum.

What Happened to 75%?

I'll be generous and allow that 1% can definitely be poisoned, then there's 2% that are 'very likely' and using their odd phrasing, 9% that are potentially vulnerable.

What it really comes down to, using their numbers, is that a little over one-half of one percent of the servers polled can be poisoned. The 'very likely' and 'potentially vulnerable' language is dubious. Unless the person checking for the vulnerability is predicting the future or unclear about whether a server is vulnerable or not, 'potentially vulnerable' means nothing as DNS poisoning is pass/fail is it not? So the servers polled either passed or failed, as noted by the 16,000 number.

So let's dig a bit into this 'very likely' number. The server passed but got some warnings? But wait, those are warnings, but the server still passed correct? Does this mean they are anticipating new types of attacks that could exploit criteria mentioned in the warnings?

Yes? No? If yes, and they know how the server could be exploited, then why not make that a pass/fail/ If no, then they're simply bolstering the numbers.

As it stands, using their numbers, less than 1% open to poisoning is a relatively minor threat. The 'potentially vulnerable' bit sounds like FUD and still only comes up to 9% which is nowhere near the 75% figure that was being tossed around earlier.

Granted, the 75% number was a reference to the number of servers that allow DNS recursion, but who cares about that figure if less than 1% can actually be poisoned.

So, for me, this sounds like a fear campaign to hype demand for a future 'solution', that will of course, have a profitable margin.

Let's look at another survey...

Quote:
There are about 9 million DNS servers on the Internet, Kaminsky said. Using a high-bandwidth connection provided by Prolexic Technologies, he examined 2.5 million. Of those, 230,000 were identified as potentially vulnerable, 60,000 are very likely to be open to this specific type of attack, and 13,000 have a cache that can definitely be poisoned.

2005-08-03 - CNET News.com - DNS Servers - An Internet Achilles' Heel
http://news.com.com/DNS+servers--an+Internet+Achilles+heel/2100-7349_3-5816061.html

And even if the numbers are on the lower side as we all know statistics are just that, they are still alarming as the people who are experts in this area are attempting to warn those responsible to clean things up.

Instead of downplaying this, why not look at it from the perspective that all these security firms and Internet researchers are doing?

Quote:
230,000 were identified as potentially vulnerable, 60,000 are very likely to be open to this specific type of attack, and 13,000 have a cache that can definitely be poisoned.

Even at the low number of 13,000, exactly which servers are the ones being poisoned? Is it possible we have an 80/20 rule in effect here? What if just 5 of those were being used to poison a major brand? What are the ripple effects of that?

P.S. In a related issue, 101 Brands were hijacked in 2006 January.
http://www.antiphishing.org/reports/apwg_report_jan_2006.pdf

Anticipating vs. Experiencing

Quote:
Does this mean they are anticipating new types of attacks that could exploit criteria mentioned in the warnings?

Yes, it means they are anticipating attacks based on having experienced them over the last 6 months.

WTF?

That PDF is about social engineering, key-logging and proxies.

>>having experienced them

Nope. Sorry. If they've experienced the attacks then the server is either open to poisoning or not correct? Then servers vulnerable to those types of attacks should FAIL, not simply receive a warning.

We're still left with less than 1% of servers being open to DNS poisoning and *I* used *their* numbers to find the percentage.

What am I missing here?

Technical Subterfuge

Quote:
Technical subterfuge schemes plant crimeware onto PCs to steal credentials
directly, often using key logging systems to intercept consumers online account user names and passwords, and to corrupt local and remote navigational infrastructures to misdirect consumers to counterfeit websites and to authentic websites through phisher-controlled proxies that can be used to monitor and intercept consumers’ keystrokes.

That report is also about Technical Subterfuge. A lot of this research crosses over into other aspects of cache poisoning which leads to phising and pharming exploits.

the lawyer's rule of thumb ...

follow the money

This is my first rule of thumb when considering the worthiness of warnings issued on the internet.

What axe is the writer grinding? What value is there for the writer in gaining exposure?

For example, a security company issuing security warnings has a vested interest in the sky falling as long as it provides a related service or product. Case in point, Netcraft covers all kinds of outages. They also offer pen testing services, server monitoring services and so on. And Netcraft is relatively responsible and factual in their reporting. Still, their coverage and reputation have an impact on their bottomline.

Even industry organisations fall into this trap. Increased exposure means validation of their mandate. Job security anyone?

Finally, for industry commentators, sensational falling sky reports are much more interesting as topics to report on, given the need to maintain and boost readership.

As far as antiphishing.org goes, I have not found on the site any mention of a sponsoring group, founding members, or current membership. The whois and a single press release on the site tie the owner to tumbleweed who operate commercially in internet security products.

75% ... 9% ... 2% ... 1% ... 0.52%

The 0.52% number is a straight calculation from Dan Kaminsky's numbers. It presumes that the numbers have been properly transcribed in the post quoting them. And that the sample used was not skewed.

With respect to dns highjacking as applied specifically to consumers being misdirected, 0.52% is a huge overstatement.

And here is the reasoning:

By definition, the consumer misdirection is caused at the consumer end of the dns infrastructure. Taking the example of North America, the largest proportion of consumers are served by the big 5 isp's. Those isp's run caching dns systems for their subscribers to use. Notice the use of the terminology dns systems when referencing their dns servers. This is an emphasis on the likelihood that the servers for a particular isp have a common configuration. Between them, at say 20 servers each, the big 5 would have 100 servers. The math, oops, lets downgrade that to arithmetic, becomes 100/9000000, since the actual target population must be compared to the actual total population. The answer is 1.1111(E-5) with rounding. In other words, so small my calculator does not want to show it in decimal format. If someone has a better calculator they can convert it and let the rest of us know. The point is, the number of dns servers that would affect the lion's share of the consumer population is infinitesimally small.

Of course, this whole thing started with the presumption that authoritative name servers of web hosts somehow participated in cache poisoning. It was further presumed that recursion automatically equaled cache poisoning. That would require a wholesale revamping of reality.

Presumption?

Quote:
Of course, this whole thing started with the presumption that authoritative name servers of web hosts somehow participated in cache poisoning.

Actually it started with a warning from the US-CERT, various security firms, Internet researchers, etc.

Quote:
It was further presumed that recursion automatically equaled cache poisoning.

No it wasn't plumsauce. It was presumed that due to the allowance of DNS Recursion for non-authoritative DNS queries on one's server that the exploit for DNS Cache Poisoning was/is a vulnerability.

All I can hope for is that those reponsible for DNS are following along and are correcting any issues they may see in their configurations. If it this doesn't affect them immediately, at least they can be prepared for it when it does happen. I find it really hard to believe that all these big names in the DNS industry are crying wolf right now. I really do plumsauce, and until you can dispel all the other reports (from the authorities including the US-CERT) that are surfacing that are related to DNS Recursion, DNS Cache Poisoning, PPC Hijacking, Pharming, Phishing and whatever other names you want to use, I shall continue to inform.

Quote:
As far as antiphishing.org goes, I have not found on the site any mention of a sponsoring group, founding members, or current membership.

Can someone help plumsauce remove the malware/spyware/adware that they have on their system?

If you continue to try and discredit the http://www.antiphishing.org/ site, I do believe you'll only be discrediting yourself. I'm convinced that your browser has been hijacked and you are not seeing the same site that most of us are.

Here are just a few of the APWG Sponsors.

Adobe
Aladdin
Earthlink
ebay
Experian
GeoTrust
Go Daddy
MasterCard
McAfee
Microsoft
NameProtect
Netcraft
Panda Software
PayPal
Symantec
Trend Micro
Visa

antiphishing.org

The names you list are not listed as members.

They are listed as "research partners". Given the looseness of the usage of the word "partners" on the internet, this means nothing without definition.

Okay...

Quote:
Membership is open to qualified financial institutions, online retailers, ISPs, the law enforcement community, security solutions providers and research institutions. Note that because phishing attacks and email fraud are sensitive subjects for many organizations that do business online, the APWG has a policy of maintaining the confidentiality of member organizations.

You're just too much plumsauce. I've got a bunch of new documentation just waiting for you. Keep it up. ;)

Quote:
They are listed as "research partners". Given the looseness of the usage of the word "partners" on the internet, this means nothing without definition.

NO THEY AREN'T! WTF are you looking at plumsauce?! Care to share whatever it is that you are tokin' while in retirement? They are listed as APWG Sponsors. You're not even looking at the site correctly.

Why plumsauce?

Why are you trying to discredit the www.antiphising.org site?

Quote:
Anti-Phishing Working Group
The Anti-Phishing Working Group (APWG) is the global pan-industrial and law enforcement association focused on eliminating the fraud and identity theft that result from phishing, pharming and email spoofing of all types.

APWG Members
- 2300+ members
- 1500+ companies & agencies worldwide
- 8 of the top 10 US banks
- 4 of the top 5 US ISPs
- Hundreds of technology vendors
- National & provincial law enforcement worldwide

Dude, I seriously believe you've been hijacked. I wonder if there is a possible DNS Cache Poisoning exploit occurring somehwere in your upstream?

the sky is falling ..

No, the headline at isc.sans.org is actually "Internet Storm Center Returning to Green" from the isc handlers diary on April 08/2005.

http://isc.sans.org/diary.php?date=2005-04-08

Quote:
You may have noticed that the InfoCon has returned to Green. We do this not because we think the DNS cache poisoning is solved, but due to that we now understand the issues and have clear things people should do to protect themselves.

Similarly, posadis.org summarised it pretty nicely:

http://www.posadis.org/dns/news/20050202-bright-ip-spoofing

The solution here is simple: just upgrade to a recent version of basically any DNS server: recent versionf of BIND and MS-DNS, and all versions of other software such as Posadis, MaraDNS and DjbDNS do not have this (pretty stupid) problem.

Even the usually hyperactive crowd at slashdot were yawning last year:

http://it.slashdot.org/article.pl?sid=05/04/08/1528213&from=rss

Nope...

Quote:
No, the headline at isc.sans.org is actually "Internet Storm Center Returning to Green" from the isc handlers diary on April 08/2005.

plumsauce, again, I have to question what your smokin'. You're quoting a particular incident that had to do with Comcast and Microsoft.

Quote:
The solution here is simple: just upgrade to a recent version of basically any DNS server: recent versionf of BIND and MS-DNS, and all versions of other software such as Posadis, MaraDNS and DjbDNS do not have this (pretty stupid) problem.

Yup, it's that simple. But, why should they? If those servers that are being affected are owned and operated by those who may be involved in these types of attacks, why should they upgrade? They may be profiting from the vulnerabilities.

Old Stuff

plumsauce, you keep referencing some older stuff on this. I've been providing you with links to recent stories on this and the fact that there are new exploits appearing out there that all lead back to the DNS Recursion issue and DNS Cache Poisoning.

Would you care to take the one major authoritative document in all of this (from the U.S. Government) and dispel what they are recommending? That would be the US-CERT site.

http://www.us-cert.gov/reading_room/DNS-recursion033006.pdf

Is the Government hyping this? Are they crying wolf? Are they being Chicken_Little? Are they distributing FUD? What financial gain to they achieve from this?

antiphishing.org

Discredit? Nope.

Establish bonafides? Yes.

I was all over that site last night, but do admit to not reading every press release. What I did state, I did see.

presumption

It was further presumed that recursion automatically *equaled* cache poisoning.

No it wasn't plumsauce. It was presumed that due to the allowance of DNS Recursion for non-authoritative DNS queries on one's server that the exploit for DNS Cache Poisoning was/is a vulnerability.

Would a change of the word *equaled* to *permits* satisfy you then?

Perhaps *automatically allows* then?

Bearing in mind of course, that we are talking about something other than ancient/deprecated software versions.

careful

Yup, it's that simple. But, why should they? If those servers that are being affected are owned and operated by those who may be involved in these types of attacks, why should they upgrade? They may be profiting from the vulnerabilities.

This is irrelevant because the dns servers of miscreants will not affect the visitors' dns servers *if those servers* are properly configured.

Have you at least accepted that the dns servers that should be focused on are those of the visitor and not those of the host?

IF?

Quote:
This is irrelevant because the dns servers of miscreants will not affect the visitors' dns servers *if those servers* are properly configured.

If? Apparently they are not properly configured or we would not be having these discussions, would we?

Quote:
Have you at least accepted that the dns servers that should be focused on are those of the visitor and not those of the host?

Nope, I'm not convinced. Not after reading what I've been reading and how everyone is so busy focusing on the big picture that the issues downstream are being overlooked.

Pharming via DNS Cache Poisoning

Let me inject a fairly new term in our industry, Pharming

Quote:
DNS (Domain Name Service) cache poisoning has been in the news this year (2005) along with a new phenomenon called pharming. DNS cache poisoning has been around for a long time, as has DNS itself. Occasionally a major exploit is discovered that brings DNS to the front of the news, but generally these attacks are perpetrated against poorly configured servers. Unfortunately in the world of DNS, server misconfiguration is an all too common phenomenon; yet this has gone on for some time without raising alarms. That is, until spammers caught on to the fact that they could use DNS cache poisoning to perpetrate fraudulent activities. Thus pharming was born and has become a major item in the news.

I leave the above for you to assimilate and try to dispel.

Quote:
For example, a security company issuing security warnings has a vested interest in the sky falling as long as it provides a related service or product. Case in point, Netcraft covers all kinds of outages. They also offer pen testing services, server monitoring services and so on. And Netcraft is relatively responsible and factual in their reporting. Still, their coverage and reputation have an impact on their bottomline.

Okay, let me pull out one of my hole cards. Instead of looking at the above profiteers, let's look at the others who may profit.

Affiliate Marketers
2nd Teir PPC Campaigns
DNS Forwarding Services
Domain Name Parking Services
Domain Name Forwarding Services
Content Network Advertising (in general)

So, we have two distinct groups that profit from either hyping the issue or attempting to mythicize it (not directed towards anyone inparticular). I think I'll go with the groups that have the loudest voice at the moment.

Even if I've misinterpreted just a small portion of this, the threat is there and it is being documented. You can reference all the old stories you wish (I have too as part of the historical timeline), but please, take a moment to read all the latest activities that revolve around DNS Cache Poisoning exploits.

FWIW

I'm not enough of a techie to understand this stuff easily, but I got curious and checked some domains with the link P1R provided earlier, http://www.dnsreport.com/

Two out of eleven sites got a bright red FAIL message for having open DNS servers. (Fortunately neither was one of mine!)

"ERROR: One or more of your nameservers reports that it is an open DNS server. This usually means that anyone in the world can query it for domains it is not authoritative for (it is possible that the DNS server advertises that it does recursive lookups when it does not, but that shouldn't happen). This can cause an excessive load on your DNS server. Also, it is strongly discouraged to have a DNS server be both authoritative for your domain and be recursive (even if it is not open), due to the potential for cache poisoning (with no recursion, there is no cache, and it is impossible to poison it). Also, the bad guys could use your DNS server as part of an attack, by forging their IP address. Problem record(s) are ...."

Here's an interesting one

Here's an interesting one

Interesting DNS Report

Thanks buckworks, that's an interesting one and worth discussion. This question goes out to the DNS Experts (digitalghost, plumsauce, stever)...

In the above situation, what risks are present due to the failures on this particular DNS Report? Let's address the first failure, Open DNS Servers. What are the potential vulnerabilities for the linkshare.com domain?

Testing Grounds

Maybe we can get those who perform this type of testing to focus on specific industries. Let's start with the link exchange industry. Then move into the affiliate space. From there we'll do one on 2nd tier PPC providers. And so on and so forth. I'd be interested to see if the problems can be narrowed down to specific sectors.

here is an interesting

here is an interesting article

http://usergram.com/dns/poison.htm

paragraph 10
"The bottom line is that the warning messages seen at dns testing sites, such as recursion being turned on, are of a informational nature. The tests have no knowledge of the usage of the dns server being tested. It is the responsibility of the reader to interpret the meaning and applicability of such messages in their own circumstances."

paragraph 11
"It is also true that a dns server offering recursion is not automatically subject to cache poisoning. It depends on whether the dns server software being used is subject to cache poisoning through recursion"

I'm not saying no DNS servers are not at risk but you seem to be putting too much fear into your findings

Fear into Findings?

Quote:
I'm not saying no DNS servers are not at risk but you seem to be putting too much fear into your findings.

Really? Can we also say that all the other reports on this recently are putting too much fear into their findings?

By the way, the link you provided is plumsauce's response to these topics. We also link to that document from our coverage of this.

Paragraph 10 and 11 don't tell me anything new or that plumsauce hasn't already hammered home elsewhere.

It doesn't change the fact that those who specialize in this stuff are issuing warnings now. If you fail for the above tests and your servers allow for these types of vulnerabilities, what exactly happens? No one has really stepped up to the plate to offer a detailed list of the vulnerabilities. I'm trying to do that but am running into a brick wall here (brick1 - digitalghost, brick2 - plumsauce, brick3 - stever, and now brick4 - mick g) at TW. ;)

By the way mick g, the server that the site in your profile is hosted on fails for the Open DNS test. I'll assume that you've got yours taken care of?

yep its taken care of

yep its taken care of pageoneresults, I have had my hosting company spend most of the morning checking to see if it was a major problem due to your findings and have been advised that its not

to quote
Nothing at all to worry about. ns.xxxx will not allow it's cache to be poisoned.

are you saying its still is a problem ? I am all ears pageone

Problem? Potentially yes...

I can only echo what the experts in this are saying...

Quote:
Kaminsky agreed. "If you are a DNS administrator, you shouldn't be providing recursive services to the Internet anymore. It is unfortunately no longer a responsible thing to do," he said. Increasingly, DNS is going to be used in attacks, experts said, and their administrators can no longer afford to be lazy.

"There are a multitude of these kinds of storms that are rising, and service providers and enterprises need to figure out how to make sure that their sea walls, dams and dikes and levees are high enough to withstand them," Mockapetris said.

I believe one of the experts here stated that the worse that could happen is that your server would be used in a DDoS attack and/or aid and abet the exploit of *another* domain. No big deal I would assume based on that comment? :(

Quote:
plumsauce: The *only* risk is that *your* dns server aids and abets the exploit of *another* domain. The reasons are explained in the other thread, and the further clarification I published offsite.

This from the US-CERT...

Quote:
An organization could be used as a DNS recursion amplifier if its DNS server is misconfigured. Consequently, its DNS server could be misused in a DDoS attack against another organization. An organization could still be targeted by a DDoS attack from misconfigured recursive DNS servers even if it is not running a vulnerable name server.

The above is from the U.S. Government (US-CERT) and was updated on 2006-03-31.

http://www.us-cert.gov/reading_room/DNS-recursion033006.pdf

Quote:
ns.xxxx will not allow it's cache to be poisoned.

P.S. Cache Poisoning is one of the potential side effects of allowing DNS Recursion for non-authoritative DNS queries. There may be other issues to contend with besides what this topic is specifically discussing.

Don't be a prat

Don't be a prat, p1r. You seem to take anyone addressing your admitted lack of knowledge as a personal insult.

You originally referred to people being able to solve problems with their site and dns cache poisoning by changing their own dns settings. As was pointed out (both publicly and privately), this was the equivalent saying that if you take an old version of Matt's Formmail off your site, you won't receive any more email spam.

I am glad that you are now disabused of that particular notion.

You now see fit to claim that anyone who doesn't answer your increasingly wild appeals and claims is now a brick in the wall of your own lack of understanding and I don't take kindly to my name being dragged in to your attempts to do whatever it is that you are doing.

For what it is worth, if you want to understand more about what people are talking about, go and read a book about internet protocols - TCP/IP Network Administration by O'Reilly would give you more of an idea and at least enable you to address some of the more interesting points that John Andrews and others have raised.

But then that would mean doing your learning in private, rather than the ever-so-public method that you insist on. (Now why could that be?)

Technically your correct as

Technically your correct as having a open dns server could be a problem but what I have is a open resolver, not open server

i.e. anyone can if they wish use ns.xxxxx.co.uk to resolve names into numbers but they can't update the contents of the a domain name zone

Lack of Knowledge

Quote:
But then that would mean doing your learning in private, rather than the ever-so-public method that you insist on.

Okay, I've clearly stated that I am not an expert in this both here at TW and at WebmasterWorld. I'm pretty good at disseminating information and making heads or tails of it. Apparently I've had some misconceptions about all of this and I need your help.

The first thing that led me down this path was the DNS Report and the failing for Open DNS Servers. I did a bunch of research after running a domain through the report and failing for that. During that research, I came across an alarming number of recent documents and advice from security experts that having a server that was open for recursion opened up the potential for other vulnerabilities.

So here are my questions to the experts, again...

Is the DNS Report wrong in showing that a server fails for DNS Recursion?

What does mick g need to worry about in their particular situation? Nothing at all?

What is it that the top names in the DNS industry are warning about? And why is the US-CERT also issuing warnings about this (updated 2006-03-30).

Why are there sites now that are actively pursuing those who have servers that are affected by this?

What happens when a local server (hosting) fails this test and they have hosting and DNS on the same box and allow for both authoritative and non-authoritative DNS queries?

Every time one of you reply, those same questions keep coming up in my mind.

Quote:
You originally referred to people being able to solve problems with their site and dns cache poisoning by changing their own dns settings.

No I didn't. ?

Questions that come up in my mind

Maybe, before you ask what you describe as "experts" (but who are in fact just people who know a bit about DNS) for input to your comments, would you have the politeness to respond to a few points that have been raised here:

For example:

i) what security issues, if any, are there in other levels and types of internet protocol? What is ARP? What is ICMP? What security implications do wireless networks introduce into any equation? (OK, sorry, that one hadn't been raised before!)
ii) what are common security holes related to sites using various types of shared hosting on a single server and/or IP address? How would you rate the gravity of these holes to DNS cache poisoning on one's own DNS server?
iii) what potential problems can occur when recursion is turned off on a DNS server and what issues should a site owner in control of their own DNS be aware of before doing so?

Okay...

Would you have the politeness to respond to a few points that I've raised here (the first three are raised by stever, the balance are mine):

i) What security issues, if any, are there in other levels and types of internet protocol? What is ARP? What is ICMP? What security implications do wireless networks introduce into any equation?

ii) What are common security holes related to sites using various types of shared hosting on a single server and/or IP address? How would you rate the gravity of these holes to DNS cache poisoning on one's own DNS server?

iii) What potential problems can occur when recursion is turned off on a DNS server and what issues should a site owner in control of their own DNS be aware of before doing so?

iv) Is the DNS Report wrong in showing that a server fails for DNS Recursion?

v) What does mick g need to worry about in their particular situation? Nothing at all?

vi) What is it that the top names in the DNS industry are warning about? And why is the US-CERT also issuing warnings about this (updated 2006-03-30).

vii) Why are there sites now that are actively pursuing those who have servers that are affected by this?

viii) What happens when a local server (hosting) fails this test and they have hosting and DNS on the same box and allow for both authoritative and non-authoritative DNS queries?

Answers to those questions would be greatly appreciated by those who are more knowledgeable with DNS than I. Thank you in advance for your responses.

Potential Problems

mick g, I took your issue over to the DNS Stuff Forums to see what Scott had to say. You may want to read his response as you may have issues to contend with. Actually, Scott states that you do have issues, mainly the DDoS Attack vulnerability.

http://forums.dnsstuff.com/tool/post/dnsstuff/vpost?id=1047197

Just for the record. Mick's

Just for the record. Mick's site and or nameservers aren't vulnerable to any attack over and above normal bandwidth assaults according to my teams (extensive) audit.

The directory is still the prince (2nd place to CV :P ) and will continue along it's climb to the throne. It may or may not get there but it won't die due to the current hoohahh about DNS issues.

It may well get hit hard on the climb upwards though and this if this happens it is (IMO) almost entirely due to the (non new) DNS issues being put in the spotlight and loads of people attempting shit they wouldn't have dreamt of before.

Although many intentions are almost definately well founded I fear that a little knowledge can be a dangerous thing. Truth be known, it aint an easy task finding and then implementing a DNS hijack but there can be a lot of collateral damage along the way that wouldn't have occured otherwise.

Cest la Vie. What is done is done. Let's all move along, there is nothing to see here :D

Case (iii) - and onwards

I've not had time to look at this for a while. But, I promised Pageone that I'd pop by one of the threads once I got the time to take a look at it, so here's an attempt at least to make this a bit more understandable.

These are very technical matters, so I understand the confusion. I'm not saying that this post is the be-all-and-end-all of a cache poisoning FAQ but I will try to answer some of the questions to the best of my knowledge.

Perhaps I'll be wrong one or two places, so kick me.. or better yet, correct me :-)

Stever + P1 - I'll skip Q1 + Q2 as those are not strictly about cache poisoning.

------------------------------------------
------------------------------------------

Okay, recursion... This means that a server.. no, wait...

When a client (eg. "browser") asks a DNS server for an IP adress for some domain, that server will either be authoritative for that domain or not. Say, somebody asks me what my phone number is, and I can respond to them accurately because it's mine. I'm authoritative for my own phone number, but not for my neighbours. Had they asked me about my neighbours phone number I might not have known, but then I could just walk over, knock on the door, and ask. That is recursion.

Recursion is the process where one DNS server will ask another server for information, automatically. That server may delegate the requests from the asking server to a third server that the first assumes to be more accurate relative to the specific query, ... and so on.

Assume that I'm in Denmark, ie. the "dot.dk" area. I need to find the URL "my.example.co.uk", so I type that into my browser of course. Here's what happens:

First my browser will attempt to contact a DNS server at my ISP, say "nameserver-dot-DK", asking "hey dude, what's the number for this co-dot-UK fella?"

The "nameserver-dot-DK" -- being recursive -- will say "honestly dear, I don't know and I don't give a damn, but I'll ask this guy for you anyway". Here, "this guy" is "nameserver-dot-UK", as the DK server knows that the UK server may know the information better than the DK server does.

So, the DK-server asks the UK-server, then asks the "co.uk" server, then asks the "example.co.uk" server until it finds an authoritative answer. Then the browser goes there. So, "recursive" means that we have a chain of servers asking servers.

If my ISP's server is not recursive, what will happen is this:

1) Browser sends a request for "my.example.co.uk" to ISP server
2a) Server responds "No such guy here, go home and weep", OR
2b) Server responds "Last time I checked his phone # was 1-800-ACME"

In case 3 "last time" is the cache. That may be old, and it may not be accurate information.

So, if you disable recursion you disable the possibility for your server to ask other servers when it is asked about information that it is not authoritative for.

Meaning that requests to that server -- for other domains than the authoritative ones -- will end up at (2a) or (2b).

----
The above is the non-technical version (without jargon) - it may lack accuracy in a few minor technical details but -- afaik, imho, fwiw -- it is not in any way wrong to explain it like this.
----

So, recursion is good, basically. It allows the "dot-something" name server to only stay updated about the stuff that it is authoritative for in stead of having to cache the yellow pages of the whole world - figuratively speaking.

What happens with cache poisoning is that somewhere along that automatic chain of requests described above, a server will send false input into the system. The server sending false input is the "poisoned" server.

So, that server will tell your server that say, "paypal.com" is at 127.0.0.1 in stead of their right IP. So, you end up there and you have no way to tell that you are in a wrong place, except if it looks wrong.

As that whole request line is 100% automated nobody will tell anybody of something suspicious is going on, because nobody will know, and nobody will even know how to know (those "nobodies" being servers along the chain).

Now, turning off recursion equals saying - "I can no longer safely trust the upstream servers - at least there's a chance that some of them may be giving me bogus information, and me (being a stoopid server) have no way to tell which are right and which are wrong, so... I'll just do that domain name lookup thing myself without asking anyone."

As for (IV) no, it's not wrong. It's basically saying that the information you'll get at that server may not be accurate, as that will be cached information, and not a recursive request. So it may be old information, or even faked. It might be all-OK as well, of course.

As for (V) mick_g probably has no problems, as I'd venture a guess that his web host is responsible and updates the cache as needed without inputting bogus information into it.

As for (VI) they are warning because this is a real and serious problem. Imagine if you can you being able to decide where a name such as "paypal.com" should point, for some subset of the internet population, without them being able to tell in any way...

As for (VII) people make sites for all kinds of reasons... Or, see (VI). I guess it's because they feel it's important. Honestly I wouldn't know.

As for (VIII) - all the requests sent to that server will be answered by that same server. Depending on the state of the cache on that box the answers will be accurate or not.

I hope this helps a bit. Feel free to correct errors and omissions.

just read us-cert

Just read that US CERT pdf - at least the first paragraph. They're just speaking of DDoS attacks, ie sending lots of requests somewhere. That's something else:

Basically what you do is ask some server - "hey tell me, what's Joe Does telephone number", and as you do that you simultaneously tell the server that you are not yourself, but "somebody else".

So, the server being a nice guy, responds of course: To "somebody else". Now, the funny thing is that the server does not only send the final answer, it sends all the answers that occur along the chain. Hence, when you ask 100 times you may get 1,000 replies sent to that "somebody else" - that's why they talk of it as being an "amplifier". Plus/or the respponses may be larger in terms of bytes. At least that's my understanding.

So, there are a few different things you can do with those servers. I've heard more creative things as well, such as using DNS server caches for distributed P2P storage and such.

I should add that the answers to the questions are different if the DNS server is "just" used for DoS attacks, as opposed to feeding false information. It really is two quite different things.

In any event these types of exploits are pretty serious, as they are not really stoppable. There's not a lot that the individual webmaster or web user can do to avoid being vulnerable to this.

as daveN said in his blog....

some dns servers need to be open....

Forgive my lask of understanding, but don't the latest versions of BIND protect you against this, even on an open dns server?

>> BIND, latest versions

>> BIND, latest versions

... that's all good, but this is the internet, and hence you can be sure that not everyone have the latest versions of any type of software, and among those that have, not everyone have configured it right.

:-)

agreed....

very true claus....

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.