DNS architecture flaw, serious cache poisoning vulnerability

chort · 07-10-2008, 12:02 AM

I don't see anything in the Security section about this yet, so here is the advisory. Note that pretty much every implementation of caching DNS resolver is vulnerable to this flaw.

http://www.kb.cert.org/vuls/id/800113

Most vendors now have a patch out for BIND to mitigate (but not totally resolve!) this risk. Update ASAP.

Mr. C. · 07-10-2008, 12:04 AM

I saw an announcement earlier, but didn't note the forum.

Updated my source and systems yesterday.

Thanks for the PSA.

Mr. C. · 07-10-2008, 12:07 AM

But you have to love Microslop's fix:

http://www.informationweek.com/news/...leID=208806946

chort · 07-10-2008, 12:16 AM

I'm not Microsoft fan by any stretch of the imagination, but you can't fault Microsoft because Checkpoint's host firewall is piss-poor. Microsoft had to do something drastic to resolve the issue, because their install base would be a huuuuuuuuuuuuuuuge target for exploitation if notification was released to the world before the patch was made available. Maybe this will cause Checkpoint to be more rigorous about their development process...

Mr. C. · 07-10-2008, 12:21 AM

Understood; its a big eco(ego)system. Better coordination might have been useful.

simonapnic · 07-10-2008, 02:55 PM

Microsoft rock, no need to say more. That's how they handle everything.
As for the DNS poisoning vulnerability, it's nothing serious to me.
It has been known for ages that such attacks are possible and the source port randomization patch they provide just makes it harder for a determined attacker.

Red Squirrel · 07-24-2008, 10:02 PM

Anyone know how I can confirm that my servers are safe? I ran a yum update but it only brought me to version 9.3 but 9.5 is latest. So I have a big feeling I'm not secure.

I'm surprised at the lack of information there is online at this point about this serious flaw. I'm also surprised banking sites and such have not already been hacked. I will be avoiding online banking for a bit just in case though. A hacker could change the records of a bank's site then direct to a site that looks exactly like the bank's site then get passwords etc... can get real messy.

I don't get how they managed to let such exploit slip by as DNS is such a simple protocol, there is no reason that the program should allow for zones to be written to by the application itself - it should be a user logged in as root that can write to the zones with a text editor, that's it.

But that said any way I can test my server? I realize there's a few web tools but they just automatically test the IP I'm coming from, I need to test a specific IP.

Mr. C. · 07-24-2008, 10:28 PM

http://member.dnsstuff.com/pages/tools.php?ptype=free
http://www.doxpara.com/

Red Squirrel · 07-24-2008, 10:37 PM

Those don't let me specify the DNS though, they just pick it out of thin air - it's showing my home IP (which is not even running DNS) and saying its vulnerable, but I need to know if my web server's DNS is vulnerable so I want to punch it in.

I suppose I could use lynx or wget from the server itself to check...

Edit: lynx worked. I'm not vulnerable, yay!

Code:

   Please Enable Javascript: { Login here }
   Your IP: 67.19.158.242   Near: Dallas, Texas United States

DNS Vulnerability Check

   This tool checks for DNS cache poisoning susceptibility, a serious security flaw in DNS recently acknowledged by CERT (US Computer Emergency
   Readiness Team). US-CERT VU#800113

This DNS server is NOT vulnerable!

   DNS Server Address Query source port Query ID
   No DNS servers found

How do I read the results table?

Mr. C. · 07-24-2008, 11:05 PM

The site evaluate the source ports seen when your system's DNS server queries their DNS servers to
look up their hosts (the host names are randomly generated, guarantying unique queries each time).

Your browser uses your local system's resolver and the configured DNS server to contact their site.
Their site isn't contacting your DNS server, and they can't force your system to use some other DNS server.
It has to come from a system that is using the caching nameserver you want to check.

Btw1. Does Lynx handle javascript correctly?

Btw2. Did you enable javascript for the site like the error says?

chort · 07-25-2008, 03:28 AM

Quote:

Originally Posted by simonapnic

As for the DNS poisoning vulnerability, it's nothing serious to me.
It has been known for ages that such attacks are possible and the source port randomization patch they provide just makes it harder for a determined attacker.

You should really educate yourself on this flaw, it is specifically not "just the same old thing we've known for years." The sophistication of this attack let's you poison any hostname for any client that's making requests to a vulnerable resolver, and not only that, but do it in about 11 seconds, tops. All the attack has to do is get you to load an HTML page that they control.

http://www.doxpara.com/

chort · 07-25-2008, 03:33 AM

PS here's a PERL script to run on servers to check the DNS resolver they're using:
http://michael.toren.net/code/noclicky/
Edit: Arrrg, Dan K. changed his tool so the above script no longer reports the correct information (falsely says you're safe!). I made a patch for it here:
http://www.smtps.net/issues/02-noclicky.patch
download both files to the same directory and apply the patch like this:

Code:

$ patch -p0 <02-noclicky.patch

NB: This doesn't check the resolver on the machine, necessarily. It checks the resolver the machine is using (i.e. /etc/resolv.conf, the first nameserver entry).

Red Squirrel · 07-27-2008, 01:53 PM

Quote:

Originally Posted by Mr. C.

The site evaluate the source ports seen when your system's DNS server queries their DNS servers to
look up their hosts (the host names are randomly generated, guarantying unique queries each time).

Your browser uses your local system's resolver and the configured DNS server to contact their site.
Their site isn't contacting your DNS server, and they can't force your system to use some other DNS server.
It has to come from a system that is using the caching nameserver you want to check.

Btw1. Does Lynx handle javascript correctly?

Btw2. Did you enable javascript for the site like the error says?

Yeah don't know if it uses JS for the actual test or just displaying the result. AS lynx does not handle it.

But the IP shown is in fact my server's IP, but that still does not mean it fully tested it...

After all the reading I've been doing on this issue I still don't understand how it happens. DNS is a read only protocol, its not like FTP where people can upload data. So what exactly allows people to easily change the records? I could see if someone hacks through the server's FTP/SSH then goes to edit the records, but then that would be a flaw in the FTP not DNS.

Mr. C. · 07-27-2008, 03:07 PM

If the layman's explanation doesn't help you to understand the exploit,
dig a bit deeper into how DNS queries are answered by a resolver->DNS server.

Not that this is material here, but DNS is not read-only. Heard of dynamic DNS updates ?