Ten Percent of DNS Servers Still Vulnerable

maotx writes "Even with the uproar caused by the recent DNS attacks, a recent study shows that roughly 10% of 2.5 million DNS servers show that they are still vulnerable to DNS cache poisoning. To put that a little bit more in perspective, of that 10% discovered, 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." From the article: "The use of DNS cache poisoning to steal personal information from people by sending them to spoofed sites is a relatively new threat. Some security companies have called this technique pharming."

Comments

Admins - Take some initiative!

[bigwavejas]

Why is it that the Admins can't take it upon themselves to keep their software updated with the latest patches? Instead, it takes an article like this to get them off their asses to take action. It shouldn't be this way.

This is strikingly similar to the Cisco OS debacle, where a patch had been available for some time, yet Admins failed to patch their hardware on their own. Yes, it's a pain in the ass to take your network down, but look at the alternative...Hacked!

Re:Admins - Take some initiative!

[egypt_jimbob]

This is strikingly similar to the Cisco OS debacle,

No, it isn't. Before the IOS "debacle" it was assumed that remote code execution on IOS was impossible. It's pretty hard to compromise an unpatched system if it's impossible to execute code on it, so admins didn't bother taking down their networks to run the (mostly aesthetic) patches.

Re:Admins - Take some initiative!

[WillAffleckUW]

>Why is it that the Admins can't take it upon themselves to keep their software updated with the latest patches?

You are assuming the fix is a patch. I get vulnerability reports for my servers every week.

And then there are patches like the last two Oracle patches which - get this - actually made it worse.

Sometimes it's a good idea to wait for them to patch the patch.

Re:Admins - Take some initiative!

[Burdell]

In the case of the Cisco IOS problems, nobody knew there was a problem
to be patched. That was the biggest part of the problem: Cisco's
silence.

When you run services that must be up 24x7, you don't donwload every new
IOS release and load it on dozens or hundreds (or more) of devices just
because there was a new release. IOS often has more new bugs in each
release than bugs fixed; when you find a release that has the features
you require and is stable with those features running, you don't touch
it until you find a bug, require a new feature, or Cisco announces a
security problem.

I run a relatively small network, and I'm looking at having to upgrade
around two dozen devices running IOS in six cities (a number of which
require visiting an unmanned office because some things can't be
upgraded remotely) plus another dozen or so devices in our spares
inventory in two cities. I'm not going to upgrade any operating devices
until I can test new releases in a test setup. All of that takes a lot
of time, which means something else has to get pushed back.

bad math

[rwven]

with almost all of the potentially vulnerable ones they only said really that 73k of them were vulnerable to something... and only 10k of those "definately" were.... 73k = 2.92% The onlther 230k might not have been vulnerable at all, they just think there's a chance that they might be. This, ladies and gents, is called sensationalism...

How can I check my own DNS configuration for this?

[Anonymous Coward]

...or for any other DNS exploits, for that matter?

Any good tools to (or sites to help) check for those?

Re:DJBDNS -- rocks

[arivanov]

Correct.

Apples and oranges.

There are places where you would have to use BIND and places where you can get away with a partial implementation. If an ISP is using DJB-DNS I would recommend to stay away from it. There is a number of neat tricks in the bind cache expiration algorithm (from late 8 and early 9 onwards) which DJB has blamed unnecessary (see the BUGTRAQ archives for the discussion). While they are not necessary they are essential to ensure that operational mistakes have a limited life. That does not happen with DJB implementation as well as some other ones. So if you screw up your TTL or serial no on the zone files - this is it. Same for poisoned entries.

Further to this. DNS is the most easily upgradeable service. Clients fallback automatically and a few seconds of downtime are in the "who cares" area. In fact every ISP out there has scheduled daily mandatory reloads which update configs. Do users notice - nope.

Even further to that, there are methods to make any number of dns servers answer the same address and because DNS is stateless this can be done without any clustering crap. ISC which writes bind have done this for 7+ years. Most global telcos and ISPs do it as well.

And, in order for DNS poisoning attacks to be effective name servers usually need to have both recursion turned on and return authoritative answers. Doing this on an internet facing server is an idiocy. If your ISP does that and serves authoritative requests from the same server which is used for name resolution in clients - RUN. They have NO CLUE WHATSOEVER. If they use clustering for resilience - run even faster.