Slashdot Mirror
Attack Code Published For DNS Vulnerability
get_Rootin writes "That didn't take long. ZDNet is reporting that HD Moore has released exploit code for Dan Kaminsky's DNS cache poisioning vulnerability into the point-and-click Metasploit attack tool. From the article: 'This exploit caches a single malicious host entry into the target nameserver. By causing the target nameserver to query for random hostnames at the target domain, the attacker can spoof a response to the target server including an answer for the query, an authority server record, and an additional record for that server, causing target nameserver to insert the additional record into the cache.' Here's our previous Slashdot coverage."
This has to be the worst time ever to be a web surfer. How long until we see the major networks broadcasting the legit IP quads of sites we want to reach?
And here I am, thinking I was on Google.
And lo, all unpatched websites were rendered unto Goatse.
It doesn't work that way. DNS local servers are either run by a corporation or by your ISP. Either one could be hacked now. So it's not if the website is patched. It is if the DNS server your computer is using is patched.
unpatched websites
Have you been following this story. It's not sites that need the patch, it's DNS servers. Site owners are powerless if the ISPs fail to protect their domain name from the an entry leading to the spoof site's IP address.
I exploited this and let a huge cache of people visit my site(127.0.0.1) in stead of the site they wanted to go. It was kickass.
Knowledge is power. Knowledge shared is power lost.
The fix is DNSSEC.
For fuck's sake, whoever is DDoSing 4chan needs to stop already! The tards have spread out and are trolling the whole internet. At least the 4chan cesspool kept them all mostly in one place. Now they're left with nowhere to go and are taking their idiocy all over the internet!
There's a tool on the site below that apparently checks if the DNS you're currently using is vulnerable to such an attack. I checked my work DNS and my home DNS - both were fine. Apparently OpenDNS is secure as well, so there's probably nothing to worry about.
http://www.doxpara.com/
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
try http://ftp.debian.org/
for a bit more info:
http://wiki.debian.org/ftp.debian.org
Um... even if you run your own caching server, if your ISP runs a "transparent" web proxy it will do its own dns. You may in fact run DJB which is immune from this bug, but if your ISP runs an unpatched dns server you'll still be scrod despite running your own caching server.
Slick huh?
They need to take the dns lookup out of the web proxies.
Need Mercedes parts ?
Congratulations, you confused the mods. Bailiwick checking was added to all DNS resolvers in response to glue poisoning and made cache poisoning through spoofed glue records very difficult. The current problem is that the typical filter rules are insufficient for stopping a glue poisoning attack which appears to come from the authoritative server: Kaminsky found a way around the glue poisoning countermeasure. This means that a very dangerous kind of attack which was thought to be defeated is now possible again.
Cédric Blancher's annotated command-line exploration of the “in-bailiwick” DNS vulnerability
It only works because the DNS server caches the result of the glue record, against the recommendation of the above writer.
The glue record is necessary if, say, you need to provide the address of a nameserver when you provide the name of the authoritative nameserver for a query. You should use that glue record for that query only.
What happens is that an attacker queries lbixds.google.com (or some other nonexistent domain) and then sends the server he issued that request to a response to that query that also has a glue record giving a false address for ns.google.com. If the DNS server only used that false address for resolving lbixds.google.com, cached lbixds.google.com, and left it at that, then lbixds.google.com would be the only entry the attacker could poison -- basically useless. However, the DNS server caches the glue record giving the address for ns.google.com, too.
They need to take the dns lookup out of the web proxies.
The problem with doing that would be that it would then be impossible (at least using current DNS software, as far as I know) to allow clients on an internal network to have limited internet access without allowing them to perform DNS tunneling (and thereby upgrade their internet access to "full").
Once someone (anyone?) releases a DNS package that allows firewall-style rules (e.g. "client on this range of IPs may only resolve subdomains of the following domains...", "clients may only look up X distinct subdomains each of Y domains every Z hours" then the picture would probably change.
"...always new atoms but always doing the same dance, remembering what the dance was yesterday." -Richard Feynman
DNSSEC is a steaming pile, though after thirteen years, many RFCs -- each of which read "This Time For Sure!" -- it may in fact be workable.
It is _a_ fix to this problem, but there are many simpler fixes that seemingly are being discarded for reasons I don't quite understand -- perhaps more full threat models are the target problem, but securing DNS doesn't make sense if we're then going to use HTTP to the addresses resolved! On the flip side, if we were using TLS everywhere, then dicking with DNS amounts to a DoS, which is much less powerful than the arbitrary redirection attacks we have now.
One such simpler fix is using EDNS0 to add a nonce RR (goes out in the Query, comes back in the Additional section). And while EDNS0 is subject to rollback attacks, DNSSEC depends on EDNS0. So that's not an excuse not to use it.
Anarchy$ dd if=/dev/random of=~/.signature bs=120 count=1
Once someone (anyone?) releases a DNS package that allows firewall-style rules (e.g. "client on this range of IPs may only resolve subdomains of the following domains..."
I think you might be able to do that with the "views" feature of ISC BIND v9 named, although I've never tried. I know you can define ACLs for clients and control how they see the DNS using the ACL. You should be able to define forwarding zones for the domains you want to work, and blackhole everything else. I think.
http://www.isc.org/sw/bind/arm93/Bv9ARM.ch06.html#view_statement_grammar
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
I used one of the tests below and found that my ISP's DNS servers were vulnerable. Now I am using the OpenDNS servers on all of my clients instead:
208.67.222.222
208.67.220.220
Their servers are not vulnerable, and you can create an account to enable things like antiphishing at the DNS level (much better idea then a browser plug-in).
If you find that your ISP's routers are vulnerable, your best bet is switch to OpenDNS...or just run your own caching server.
ÕÕ
In case anyone is dumb enough to use a Microsoft DNS server as a authoritative internet DNS server -
MS has released two lovely patches -
KB951746 and KB951748
The problem with this fix is that it turns the DNS.EXE daemon into a UDP socket grubbing whore.
After the patch, the DNS.EXE daemon grabs no less than 2500 freaking UDP sockets.
This wreaks havoc on anything that - you know - needs UDP sockets on the same server.
So far Zonealarm, Blackberry BES and Sphericall VOIP software all break with this "patch"
Stay tuned for more fun to come ...
---- "Logoff! That cookie shit makes me nervous!" - A. Soprano
Simply patching your DNS server may not be enough.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
So, first part. An attacker is trying to poison a DNS cache. Generally, he'd be interested in poisoning a DNS server that's a caching server for a group of people, like one run by a regional ISP. An efficient way of getting a poisoned record into its cache is to issue a request to that server, and then immediately send a forged response to the server. So, for example, I issue my local nameserver a request for abcd.google.com. It doesn't have this cached (you don't say!), so it starts trying to resolve it. I quickly send it a forge response for abcd.google.com, and it believes me. Transaction IDs make this a slim chance that it'll believe me, but it's still a chance, and I can issue a ton of requests to different fake addresses.
The answer to the second part is tricky. Basically, say I want to resolve mail.google.com. I have nothing about google.com in my cache. So I contact the nameserver for .com. It isn't authoritative for the google.com domain, but it knows who is, and it tells me so. (Say that it's ns.google.com.) Knowing ns.google.com is the nameserver for that domain is useless without its IP address, so it tacks on a glue record that gives me the address of ns.google.com. Now I can contact ns.google.com to ask it the IP of mail.google.com.
Originally, these records were just accepted. This is a huge security hole: I could request bob.domainiown.com, send a legitimate response (I control domainiown.com), and tack on a record telling them where ns.google.com is, even though I'm not authoritative for that. Now, such a record can only be attached to a request that is in the same domain, so I need to ask for bob.google.com to attach an ns.google.com record, which requires me to forge a response.
There are a number of situations where these auxiliary records are necessary, so they can't just be ignored. However, they shouldn't be cached -- they should be used only for the one request that generates them.
Most of these routers don't run caching, recursive resolvers -- they just forward the request to your ISP's DNS server. As such, they are immune.
A Google search revealed this way to test specific DNS servers from the command line (in case you're using a DNS server other than the one that's authoritative for the netblock you're in):
Good:
$ dig +short @208.67.222.222 porttest.dns-oarc.net txt
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"208.67.222.222 is GOOD: 26 queries in 0.1 seconds from 26 ports with std dev 17746.18
Poor:
$ dig +short @206.13.28.12 porttest.dns-oarc.net txt
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"206.13.28.13 is POOR: 26 queries in 0.2 seconds from 1 ports with std dev 0.00"
More discussion on this method here:
http://www.dslreports.com/forum/r20759262-CERT-VU800113-DNS-Cache-Poisoning-Issue~start=20
Maybe it wasn't clear, but I was going to echo nweaver's reply:
djbdns's total lack of support for glue records (IIRC) is one of the reasons it's one of the few old dns software not vulnerable. And that's the point I was trying to drive: the glue records feature made the cache poisoning possible -- I just read the exploit code, and it uses Additional Section to inject the malicious entry. Without this feature, like in djbdns, the exploit wouldn't work.
Yeah, I should have said "don't cache glue records", not "make it stricter" mea culpa.
"DNSSEC is a steaming pile"...
Yes! Unfortunately this is completely and utterly true. Unlike many of the great crypto tools we have available to us (ssh, pgp, https), DNSSEC increases complexity by an order of magnitude.
Watch as you lose the ability to effectively block full zone transfers from your domain name since DNSSEC requires NSEC records, which are essentially a linked list of all your zone entries!
Be amazed when you find out that you need to run a cron job to sign all of your zone files every 15 days!
Become aghast when you find out that you then need a second cron job, running on an alternate server, that runs a script that checks all your zone files for signature expirations.
Become horrified when you find out that a properly validating DNSSEC caching server will block domains with expired signatures with NXDOMAIN, since there were only four choices in the existing DNS protocol and that response was the least bad.
Smirk as you find out that virtually no one at all is using DNSSEC. Run `dig nsec $DOMAIN` against some well known DNS zones, and find that practically no one (except for the ISC) is using it.
Since there are political problems with the key signing heirarchy, ISC is setting up an alternate place to put your higher level keys in their DLV registry. .com and .net are not going to be implementing DNSSEC.
I have gone through and encrypted everything I could on my servers recently. I attended a presentation by ISC about how great DNSSEC is. I came away convinced that it was a lot of hot air, and that ISC was trying to sell the Internet a bill of goods. DNS isn't perfect, but DNSSEC is a half baked solution that virtually no one wants, and I frankly can't ever see it ever becoming popular in anything approaching its current form. Not ready for prime time... back to the drawing board guys!